GNOME Bugzilla – Bug 446792
gThumb deletes pictures on failed import
Last modified: 2007-07-19 14:46:29 UTC
Please describe the problem: Importing pictures failed (with gThumb displaying lots of error messages) but gThumb still deleted the pictures from the camera. I was very lucky to have imported the pictures to another computer or I would have lost them! The reason the import failed is reported by gThumb as follows: "Could not move temporary file to local destination. Check folder permissions." This may be related to the fact that gThumb uses a directory that's under a bind mount because I've seen that gThumb cannot correctly move pictures to the trash bin either (error message: file not on the same volume). Steps to reproduce: 1. Somehow make sure that the import fails 2. Find a lot of error messages on the screen (one for each photo) 3. Find no pictures on your disk and no pictures anymore on your camera either Actual results: pictures > /dev/null Expected results: no change to the pictures on the camera (and preferably no import failures of course, but if they happen they shouldn't cause loss of data) Does this happen every time? don't know, I'm not sure how to reproduce this Other information: I'm using gThumb 2.10.2 as supplied by Ubuntu
Temporary workaround: disable the rotation-on-import feature. The problem is occurring in the rotation code. A temporary file is generated by the rotation code, which is then gnome_vfs_xfer_uri'd to overwrite the input file. Possibly related to bug 309592. - Mike
Could you clarify the filesystem arrangement that caused this problem? Are /tmp and the image directory on different filesystems? How are they mounted, exactly? - Mike
/tmp, /home and /photos are all on / (no separate mounts) then I have a bind such that /crypt contains everything that / contains mount displays among other things: /dev/mapper/root on / type ext3 (rw,errors=remount-ro) / on /crypt type none (rw,bind) gThumb uses the directory /crypt/photos, so it thinks that it's using a different filesystem than /tmp, while that's not actually the case. (The reason for the bind is to make this system look the same as my other computer's.) It's true that I had rotation switched on.
*** Bug 446992 has been marked as a duplicate of this bug. ***
This problem also happened to me, except the failed import was due to the camera being disconnected accidentally.
Edward, Did you have rotate-on-import checkbox enabled? Did any error messages get reported to the console? These problems are difficult to reproduce, so details are helpful. - Mike
Edward, never mind - I just read bug 446992. - Mike
Created attachment 89902 [details] [review] Initial patch - don't delete camera files if an error occurs Here's an initial attempt at a patch to fix this. I haven't tested it enough yet; I plan to come back to this. Paolo, let me know if you dislike the approach taken here. This adds new strings to the stable branch, but I think it's worth it in this case. - Mike
I've applied the patch to svn. Hopefully it prevents the file loss. - Mike