One important thing is to assure that the thumbnail image displays the same information than the original, only in a downscaled version. To make this possible we compare the original file's size and modification time with the attribytes stored in the 'Thumb::MTime' and 'Thumb::Size' keys. The absence of the MTime key in a global thumbnail is an error; apart from that, checks are only performed if the relevant key is present. If any check fails, the thumbnail can not be used and must be recreated.

if ((!thumb.isShared && !isSet(thumb.MTime)) ||
      (isSet(thumb.MTime) && file.mtime != thumb.MTime) ||
      (isSet(thumb.Size) && file.size != thumb.Size) {
   recreate_thumbnail();
}

Relying solely on modification times may fail in cases where collections of files have been copied to a new folder. several files can share the same modification time - to within the one second resolution of 'Thumb::MTime'. Activities like swapping the filenames of these files may then result in incorrect thumbnails. Where the thumbnail includes the 'Thumb::Size' key, the extra check of comparing sizes can avoid this issue.

Note

It is not sufficient to do a file.mtime > thumb.MTime check. If the user moves another file over the original, where the mtime changes but is in fact lower than the thumbnail stored mtime, we won't recognize this modification.

If for some reason a non-shared thumbnail doesn't have the 'Thumb::MTime' key (although it's required) it should be recreated in any case.

Note

There are certain circumstances where a program can't or don't want to update a thumbnail (eg. within a history view of your recently edited files). This is legally but it should be indicated to the user that an thumbnail is maybe outdated or not even checked for modifications.