thumbnail mtime, ctime
Dr. Michael J. Chudobiak
mjc at avtechpulse.com
Fri Mar 28 03:29:52 PDT 2008
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
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
3) Storing the ctime will flag permissions changes
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.
More information about the xdg