After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 167752 - Behaviour if images no longer on disk
Behaviour if images no longer on disk
Status: RESOLVED WONTFIX
Product: f-spot
Classification: Other
Component: General
CVS
Other Linux
: Normal enhancement
: ---
Assigned To: F-spot maintainers
F-spot maintainers
gnome[unmaintained]
: 345234 449447 476275 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2005-02-17 22:44 UTC by Alexander Hunziker
Modified: 2018-07-12 00:01 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Alexander Hunziker 2005-02-17 22:44:16 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.
Comment 1 Larry Ewing 2005-02-17 23:10:13 UTC
It should definitely ask and allow the user to select the proper image.
Comment 2 Gabriel Burt 2005-12-04 05:33:52 UTC
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.
Comment 3 Lauri Kotilainen 2005-12-17 15:16:45 UTC
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.
Comment 4 Gabriel Burt 2005-12-17 22:36:32 UTC
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
Comment 5 Larry Ewing 2005-12-18 22:22:31 UTC
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.
Comment 6 Gabriel Burt 2005-12-18 22:31:45 UTC
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?
Comment 7 Bengt Thuree 2006-02-18 05:55:49 UTC
Related stuff on bug #322805 (import from removable media) 
Comment 8 Elijah Newren 2006-06-18 15:28:30 UTC
*** Bug 345234 has been marked as a duplicate of this bug. ***
Comment 9 Bengt Thuree 2006-06-26 01:22:07 UTC
Related crash in bug #345920 (Meta browsing on deleted file crashes f-spot)
Comment 10 peter gervai 2007-11-23 08:13:25 UTC
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.
Comment 11 Maxxer 2007-11-23 08:16:39 UTC
*** Bug 476275 has been marked as a duplicate of this bug. ***
Comment 12 Maxxer 2007-11-23 08:40:27 UTC
(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.
Comment 13 Maxxer 2007-12-02 09:28:07 UTC
*** Bug 449447 has been marked as a duplicate of this bug. ***
Comment 14 Markku Vire 2008-07-16 19:02:09 UTC
(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.
Comment 15 André Klapper 2018-07-12 00:01:52 UTC
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.