thumbnail mtime, ctime

[Dr. Michael J. Chudobiak]

Sven Neumann wrote:

>> What about adding file size as a comparison parameter?
> 
> If I remember correctly, the spec already specifies that the image file
> size should be stored in the thumbnail and that it should be used to
> detect changes. At least the implementation that is used in GIMP does
> this.

Yes, it specifies using mtime (in seconds). Unfortunately, this does not 
always unambiguously flag file changes.

I am proposing to add to the spec, recommending the storage of:

mtime (with second and sub-sec resolution)
ctime (with second and sub-sec resolution)
size (in bytes)

and -optionally- allowing all five parameters to be used to judge 
freshness. Only mtime (in seconds) would be mandatory for storing and 
for date comparison. This maintains backward and forward compatibility.

This would have several benefits:

1) Solaris and ext4 have nanosecond mtime/ctime resolution; we should 
prepare to make use of this. (I originally said at the microsecond 
level; perhaps nanoseconds would be better. Not sure.)

2) Using high-accuracy mtimes and/or file sizes eliminates problems when 
file are written in many small chunks over a period of a few seconds 
(e.g., http://bugzilla.gnome.org/show_bug.cgi?id=432759. I sometimes run 
into this problem when saving images over a serial port from an 
oscilloscope. The current gthumb hack involves ignoring "failed" 
thumbnails if the thumbnail mtime is within the last 5 seconds.) It also 
eliminates the problem of renaming a bunch of similar files with a fast 
script (http://bugzilla.gnome.org/show_bug.cgi?id=522317).

3) Storing the ctime will flag permissions changes 
(http://bugzilla.gnome.org/show_bug.cgi?id=516125).


These changes would not happen overnight, of course, but ultimately they 
would lead to a more robust thumbnail cache. Which is important if the 
user does not have thumbnail management tools.

- Mike