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 98931 - Race condition in thumbnail generation with file creation notification
Race condition in thumbnail generation with file creation notification
Status: RESOLVED DUPLICATE of bug 432759
Product: gthumb
Classification: Other
Component: general
unspecified
Other other
: Normal normal
: ---
Assigned To: Paolo Bacchilega
Paolo Bacchilega
Depends on:
Blocks:
 
 
Reported: 2002-11-18 22:10 UTC by Jason Tackaberry
Modified: 2007-06-14 11:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Jason Tackaberry 2002-11-18 22:10:02 UTC 
It sometimes happens that gthumb detects a new file exists in the current
directory being monitored and begins generating the thumbnail for that file
before the file has finished copying.  This results in a corrupt thumbnail.

Probably the best solution would be to add a timer to a "new file" event,
and if the file size hasn't changed in say 100ms, it's okay to start
generating the thumbnail.
Comment 1 Jason Tackaberry 2002-11-18 22:16:49 UTC 
Actually I see that gThumb also handles "file changed" events, so a
timer isn't needed.  If I 'touch' the file with the broken thumbnail,
it gets regenerated.  There's still clearly a race condition
somewhere, though. :)
Comment 2 Amir Yalon 2005-06-04 18:56:31 UTC 
I was just about to file a new bug report on this...
In the meanwhile, I navigate away from the dirs into which I am copying new photos.
Thanks for the tip about 'touch'ing the files to get the correct thumbnail.
Comment 3 Michael Chudobiak 2007-06-14 11:55:23 UTC 
This has been fixed. The fix will be in 2.10.4 and later. See bug 432759.

*** This bug has been marked as a duplicate of 432759 ***