thumbnail mtime, ctime

Thiago Macieira thiago at
Fri Mar 28 04:03:07 PDT 2008

On Friday 28 March 2008 11:37:38 Dr. Michael J. Chudobiak wrote:
> Thiago Macieira wrote:
> > I don't think a failed thumbnail should be saved under those conditions.
> The spec says "For every thumbnail generation failure the program
> creates an empty PNG file." It doesn't exclude permissions-related
> failures. And that is certainly how it has been implemented in gnome.
> However, I think you're missing the broader point: by storing some extra
> metadata in the thumbnail (mtime seconds + subseconds, ctime seconds +
> subseconds, and file size) we can painlessly eliminate the existing
> ambiguities in identifying file changes. The information usually exists
> anyways at the time of thumbnail generation, it is just a few bytes in
> size, and it can be done in a backward and forward compatible way. So
> why not?

A couple of reasons:
 - it would trigger a thumbnail regeneration if the file did not change, but 
the permissions did (644 to 664 for instance)
 - it would throw away a valid thumbnail if the file became unreadable
 - it's slow: I can't think of a case where storing a complex file to say "I 
couldn't open this file" is a good case, even in the remote file scenario.

  Thiago Macieira  -  thiago (AT) - thiago (AT)
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : 

More information about the xdg mailing list