GNOME Bugzilla – Bug 167752
Behaviour if images no longer on disk
Last modified: 2018-07-12 00:01:52 UTC
Just some thoughts on what should happen if one deletes images from the disk while f-spot it not running. IMHO, there are essentially two possibilities what to do if f-spot detects that some images were deleted: * Ask the user what whether to keep the thumbnails in the catalogue or not. Maybe he keeps the images on some hotplug drive that is not connected at the moment...? * Don't ask the user, and just delete the thumbnails from the catalogue.
It should definitely ask and allow the user to select the proper image.
In that dialog it would be nice to have a "Remember my decision for this directory/photo" so if it was a photo stored on an external drive it wouldn't annoy the user with a dialog box every time.
For the default action, I'd go with marking the image with some descriptive emblem or highlight and add a tooltip to inform of the missing original. Double-clicking could show the thumbnail and a more verbose explanation of what's going on. Auto-removing the image could be an option, but IMO neither that nor the dialog should be the default behaviour.
I can see it being quite annoying to somone who deletes many of their photos from nautilus or some other program, loads up f-spot again, and has to remove them yet again. To account for this scenario and the others, I think the best response for f-spot would be to 1) scan for new photos and make sure the photo wasn't renamed instead of deleted (by comparing the hash) 2) Check if the drive the photo originally was on is connected, and if not, display an emblem identifying that photo as located on a remote disk 3) Automatically remove the photo from the catalog if the above two checks fail
Which would mean this logic would be triggered if the photo was just moved and we'd lose any extra metadata that wasn't stored in the image. Also I'm not sure scanning all the photos at startup is a friendly thing for an app to do. The missing mark could probably be added in the thubnail check thread though, and then we could some options inline in View mode that allow you to reconnect or remove the entry. With those options it wouldn't be perfect but it would be a lot better than what we do now.
You're probably right that we shouldn't scan on start up. Do you agree that putting a different mark on photos whose drives are not present is a good idea? And put the missing mark on ones that were deleted or renamed?
Related stuff on bug #322805 (import from removable media)
*** Bug 345234 has been marked as a duplicate of this bug. ***
Related crash in bug #345920 (Meta browsing on deleted file crashes f-spot)
I see that there are very fine and quite complex ideas, which is nice. However it is still very annoying that missing files are not visible (like a skull-and-bones tag on the image, whatever), and they cannot be easily removed. I would very much appreciate a very simple solution, namely "find missing images" (and show them only). Then I could tag 'em, remove 'em, stomp on them or put them in jelly for the winter. Any other smart solution could be nice but developer-consuming. ;-) This one may be implemented pretty fast.
*** Bug 476275 has been marked as a duplicate of this bug. ***
(In reply to comment #10) > I would very much appreciate a very simple solution, namely "find missing > images" (and show them only). Then I could tag 'em, remove 'em, stomp on them > or put them in jelly for the winter. a new extension from Bengt is on the work. That will help in finding orphaned photos and other cool stuff. this is not automatic, but will help a lot, and I believe may even close this bug.
*** Bug 449447 has been marked as a duplicate of this bug. ***
(In reply to comment #4) > 2) Check if the drive the photo originally was on is connected, and if not, > display an emblem identifying that photo as located on a remote disk I faced this scenario when I tried to use my photo library over NFS. If my laptop cannot connect the NFS server (when I'm not at home or when the server is down), the whole f-spot UI freezes. I assume that it tries to find out if the thumbnails are still valid. This causes that autofs repeteadly tries to mount the share. So, it would be nice if f-spot could detect that the original media where the photos were imported is not reachable.
F-Spot has moved to https://github.com/f-spot/f-spot/issues If this Bugzilla ticket is still valid in a recent version of F-Spot, please feel free to post this topic as a ticket in the F-Spot project on GitHub. Closing this report as WONTFIX as part of Bugzilla Housekeeping as we are planning to shut down GNOME Bugzilla in favor of GNOME Gitlab.