Problem with thumbnail mamagement for image files

[Jeffery Small <jeff cjsa com>]

There is a problem with the current implementation of thumb.MTime that I
think should be addressed.  Here is an example of the problem.

I have a bunch of image files which I copy to a new directory:

        cp  z_01.jpg z_02.jpg z_03.jpg z_04.jpg  newdir

Now, I go to the new directory and run gThumb which displays the images and
creates the corresponding thumbnails.  OK so far.  I decide that I want
to rearrange the files so I do some renaming.  For simplicity, let's just
say I decide to index them all forward by one number so that they now get
renamed:

	z_02.jpg z_03.jpg z_04.jpg z_05.jpg

I'm doing this at the shell level with my own scripts which use mv(1) to
rename the files.  At this point I refresh (or restart) gThumb, but there
is a serious problem.  The thumbnails do not get updated to reflect the
current corresponding image files.  After further investigation, the reason
appears to be that the stat(2) time entries are only recording the st_mtime
values to the second.  When the copy operation is performed and the new
image files are initially created, most or all of them end up having the
same mtime value at one second resolution.  Later, when the files are
renamed, the mv(1) operation preserves the mtimes on the files and the new
z_02.jpg (old z_01.jpg) still has the same mtime as the old z_02.jpg (now
z_03.jpg) so gThumb fails to see a change in the mtimes and will never
update the thumbnail to reflect the new image file contents.  Needless to
say, this causes great confusion and a lot of problems.

There are two possible solutions to the problem:

The first would be to store mtimes to nanosecond resolution.  Apparently
this is possible as there is a recently added -E flag on my Solaris 10
system which allows the mtime/ctime/atime to be displayed in nanosecond
resolution.  I'm not sure where these values are coming from, but a review
of the Solaris source code should reveal the proper method.  Assuming
this can also me used for Linux, this would be the preferred method of
addressing the problem.

The second solution would be to switch from checking mtime to ctime.  The
use of ctime would pick up the name changes to the files and would solve
this problem as well.

I have brought this to the attention of the gThumb developers and they
suggested bringing this request to this list since the standard detect
algorithm is:

	if (file.mtime != thumb.MTime) {
	    recreate_thumbnail ();
	}

and the change must be built into the standard gnome UI library so that it
gets picked up by all gnome applications.  I don't think that making this
change in the UI library would break any existing code.  I hope you will
consider it for inclusion in an upcoming release.  The current behavior of
gThumb is driving me crazy.  :-)

Regards,
--
Jeffery Small