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 446792 - gThumb deletes pictures on failed import
gThumb deletes pictures on failed import
Status: RESOLVED FIXED
Product: gthumb
Classification: Other
Component: general
2.10.x
Other All
: Normal critical
: ---
Assigned To: Paolo Bacchilega
Paolo Bacchilega
: 446992 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2007-06-12 16:23 UTC by info
Modified: 2007-07-19 14:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Initial patch - don't delete camera files if an error occurs (5.51 KB, patch)
2007-06-13 19:29 UTC, Michael Chudobiak
needs-work Details | Review

Description info 2007-06-12 16:23:52 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
Comment 1 Michael Chudobiak 2007-06-12 16:49:52 UTC
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
Comment 2 Michael Chudobiak 2007-06-12 16:54:29 UTC
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
Comment 3 info 2007-06-12 20:42:13 UTC
/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.
Comment 4 Edward Kaplan 2007-06-13 05:14:19 UTC
*** Bug 446992 has been marked as a duplicate of this bug. ***
Comment 5 Edward Kaplan 2007-06-13 05:15:55 UTC
This problem also happened to me, except the failed import was due to the camera being disconnected accidentally.
Comment 6 Michael Chudobiak 2007-06-13 11:34:36 UTC
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
Comment 7 Michael Chudobiak 2007-06-13 11:36:12 UTC
Edward,

never mind - I just read bug 446992.

- Mike
Comment 8 Michael Chudobiak 2007-06-13 19:29:55 UTC
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
Comment 9 Michael Chudobiak 2007-07-19 14:46:29 UTC
I've applied the patch to svn. Hopefully it prevents the file loss.

- Mike