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 522317 - Problem with thumbnails
Problem with thumbnails
Status: RESOLVED DUPLICATE of bug 523028
Product: gthumb
Classification: Other
Component: general
2.10.x
Other Solaris
: Normal enhancement
: ---
Assigned To: Paolo Bacchilega
Paolo Bacchilega
Depends on:
Blocks:
 
 
Reported: 2008-03-13 21:35 UTC by Jeffery Small
Modified: 2008-03-17 19:30 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Jeffery Small 2008-03-13 21:35:16 UTC
The code for thumbnails needs to be improved to include a check of the timestamp on the original image file so that the thumbnail can be updated properly. Here is an example of the problem: 
 
Given the files: 
 
xx.01.jpg xx_02.jpg xx_03.jpg 
 
If you manually rename/renumber these files to: 
 
xx.02.jpg xx_03.jpg xx_04.jpg 
 
Then the cached thumbnails for xx.02.jpg and xx_03.jpg will not be updated and will continue to display the old, now incorrect thumbnails. There is no simple way to get these thumbnails updated without doing a wholesale update of all thumbnails. There should be options to clear the thumbnail cache for the given folder and another to render thumbnails for a specific folder which should be able to force the recreation of existing thumbnails to address this problem. However, the code should really be updated to always check the modification times of the thumbnail against the original file and automatically update the thumbnail if the original file has a later date, indicating that it was modified in some fashion. 

It would als be a big improvement if gThumb would automatically monitor the image files and automatically update the image and recreate the thumbnail when the image changed, similar to the way gqview works.
Comment 1 Michael Chudobiak 2008-03-13 23:34:57 UTC
How are you renaming the files? With gthumb? Or "mv" on the command line?

gThumb does check for changed files. If the mtimes have changed, it should generate a new thumbnail.

If the old and new images have the same filename and the same mtime, gthumb will not be able to identify the file as changed, of course.

- Mike
Comment 2 Jeffery Small 2008-03-14 01:49:51 UTC
Mike:

Yes, I am modifying the files with an external script that uses mv(1).  I was technically in error when I said use the mtime of the file.  What really needs to be done is examine the change time (ctime) of the file such as is done using the -c flag for ls(1).  This will pick up name changes to the file in addition to modifications to the file contents and will eliminate the problem I have identified.  Sorry for the sloppy original description.
Comment 3 Michael Chudobiak 2008-03-14 12:45:11 UTC
The gnome thumbnail cache (which gthumb shares) is based on mtimes. See http://library.gnome.org/devel/libgnomeui/unstable/libgnomeui-GnomeThumbnail.html#gnome-thumbnail-is-valid for example. 

I don't see an easy fix for this.

- Mike
Comment 4 Michael Chudobiak 2008-03-14 12:59:05 UTC
Here is the spec that gnome/gthumb follow:

http://people.freedesktop.org/~vuntz/thumbnail-spec-cache/modifications.html

- Mike
Comment 5 Jeffery Small 2008-03-14 19:02:24 UTC
Mike:

What's so hard about changing the check from stat(2) st_mtime to st_atime?  This seems like a simple addition to create this function in the gnome UI library.  It could be added as a variable passed into the current function to specify either a mtime or ctime check.

Looking further into this, I see that, according to the definition in <sys/types.h>, the stat times values have a resolution only a second.  This is the problem that I am experiencing.  I often copy various image files into a new directory for some operation.  At the time that they are copied, many or all of their mtimes get set to the same value.  Then, when I later rename them, they keep their same mtimes in the process.  The problem is that the new file named zz_02.jpg now has the same mtime as the old zz_02.jpg since all the files originally started with the same mtimes.  The problem can only be resolved with mtime if it was comparing its values to the nanosecond rather than seconds.  This apparently can be done since the recent addition of the -E flag to the ls(1) command (at least on my Solaris system) can display mtimes and ctimes with nanosecond resolution.  If this change were implemented then it should be possible to continue using mtime to compare the file against the thumbnail.

Regards,
--
Jeff
Comment 6 Michael Chudobiak 2008-03-14 19:15:36 UTC
Jeff,

I suggest that you post your suggestions to the desktop-devel list (http://mail.gnome.org/mailman/listinfo/desktop-devel-list), if you have ideas for improving the thumbnailing specification (http://people.freedesktop.org/~vuntz/thumbnail-spec-cache/modifications.html).

Many apps use this spec. It's not a gthumb-only thing. It it changed, gthumb would follow.

The one-second resolution of mtime is annoying; I agree. However, that is the standard behavior on linux. I don't know anything about solaris.

You said "What's so hard about changing .... st_mtime to st_atime". You didn't really mean atime, did you?

- Mike
Comment 7 Jeffery Small 2008-03-14 19:20:45 UTC
NO!, I didn't mean atime, I meant ctime.  Sorry about that.
Comment 8 Jeffery Small 2008-03-14 19:55:51 UTC
Mike:

I'll take your advice and report this to the desktop-devel list.  In the meantime, if you cannot fix this problem directly, how about adding a thumbnail maintenance feature that allows the thumbnails in the current directory to be forced to be recreated and the display refreshed.  It would be good if this could be made a button that could be placed on the toolbar.  This would at least provide a way to manually rectify problems like the above.

Regards,
--
Jeff

Comment 9 Michael Chudobiak 2008-03-17 19:30:34 UTC
I've filed a libgnomeui bug about this: bug 523028.

- Mike


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