thumbnail mtime, ctime
thiago at kde.org
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) macieira.info - thiago (AT) kde.org
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
Size: 189 bytes
Desc: This is a digitally signed message part.
Url : http://lists.freedesktop.org/archives/xdg/attachments/20080328/d6186a69/attachment.pgp
More information about the xdg