Hi Jeffery > >Since the initial thumbnail file is created after the image file the ctime > >of the original thumbnail will always be later than the image file. So > >testing for "thumbnail ctime older than image file" isn't going to work > >reliably - this test will always be true even before any manipulations of > >the image files is done. > > >Unless you can force the ctime of the thumbnail to be that of the > >associated image I can't see how a ctime test can be used - by definition > >the thumbnail's ctime will always be "older" than the original image, so > >the resulting test would always be true. > > Correct me if I'm wrong, but the ctime reflects changes to the file's > inode, while mtime reflects changes to the actual file. Every time mtime > changes, ctime is updated as well. But if we do some operations like > changing the permission or renaming a file, then the ctime will be updated > while the mtime will remain the same.
That is correct AFAIK. > I think geeqie is checking the mtime and sees when image files are > rewritten, but it doesn't ever recognize when file names change. That would make sense. As it turns out most applications consider mtime rather than ctime so geeqie isn't unique in this. > We start with an existing image file with a set mtime and ctime. Geeqie > creates a thumbnail and this will have a newer (i.e., later) mtime and > ctime. Now, so long as the thumbnail's ctime is newer than the image file > everything is OK. If the image file is manipulated in any significant > way, including rewriting its contents or renaming it, the ctime will be > changed to "now" which will then make the existing thunbnail's ctime older > than the image file. As soon as geeqie see that the thumbnail ctime is > older than the image file's ctime, it should know that it needs to remake > the thumbnail. When it does that, the thumbnail will once again have a > newer ctime than the image file and everyone is happy once again. That all seems to make sense (I think I was still thinking of the incorrect scenario when I wrote my last comments late last night, plus I misunderstood what you meant by your ctime test). Whether this will work as expected by simply changing the existing mtime test to a ctime test probably depends on the internal representation used in geeqie to track images and their respective thumbnail files (a detail I'm not at all familiar with and therefore not in a position to comment on). Note that a consequence of testing the ctime will be that the thumbnail will be needlessly recreated if one changes permissions and/or group owner of the files concerned - these don't constitute actual image changes but there's no way to differentiate this from other operations on the file which do require a thumbnail refresh. It is fair to say that these particular operations aren't exactly common though, so it's possibly something we can live with. The only other issue I can see here is that a rename operation will leave a dangling, unused thumbnail image. This may not be that big a deal because the thumbnail repository is essentially a cache and old unused images should in theory be cleaned out (by geeqie itself, so some other service) periodically. Regards jonathan ------------------------------------------------------------------------------ ThinkGeek and WIRED's GeekDad team up for the Ultimate GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the lucky parental unit. See the prize list and enter to win: http://p.sf.net/sfu/thinkgeek-promo _______________________________________________ Geeqie-devel mailing list Geeqie-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geeqie-devel
