thumbnail mtime, ctime

Thiago Macieira thiago at
Thu Mar 27 12:58:36 PDT 2008

Dr. Michael J. Chudobiak wrote:
>>> Or your navigate to a folder, realize that you don't have read
>>> permission, so you fix it. But the thumbnail doesn't regenerate...
>> I don't see that as a valid use-case. If the file can't be read, there
>> is no thumbnail. So what would you be storing in the thumbnail cache?
>A "failed" thumbnail is saved, as per the spec.

Sorry for not seeing that before. Finding the spec isn't very easy. It's 
on the second page in Google search after you restrict to finding 
on "" servers...

>The failed thumbnail stores the original mtime, so that system knows
>when to re-attempt thumbnailing. But since the ctime is not stored,
>permission fixing will not trigger a re-thumbnailing.
>It's a valid use case, in other words :-)

No, I don't agree.

I don't think a failed thumbnail should be saved under those conditions. 
The file isn't broken or unknown -- it simply could not be read. The 
reason for saving the negative cache is given in the spec: "Eg to avoid 
trying it again and again in the future."

But, in this case, failing to open a local file is *less* expensive than 
inspecting the negative cache (i.e.,, two failed open(2) calls, as 
opposed to a successful open(2) of the thumbnail, decoding the PNG data, 
extracting the Thumb::MTime attribute and then comparing to the mtime 
from stat(2) the target file). 

Remote files, however, I can't say. There are probably too many variables 
and differences in implementation.

So, my opinion is that the gnome bugzilla link you posted is a bug in 
Nautilus, not in the spec.

  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