Hi Jeffery
> >> This is now a very serious issue as there does not appear to be a way to
> >> fix this problem short of destroying the entire thumbnail cache and having
> >> to rebuild all stored thumbnails from scratch.
>
> >If something goes and messes with the cache in this way I think it's
> >perfectly reasonable to expect that applications will behave strangely. So
> >maybe I've totally misunderstood what's being described.
>
> Well, nothing is messing with the cache - only with the original images.
Ah, *that* was the issue I missed. I though you were renaming files in the
cache; I overlooked that you were renaming the *original* files. That's
what happens when you scan emails quickly. Sorry about that.
> The problem is that geeqie is no updating the cache to reflect changes that
> it sees are occurring to the image files. There must be some sort of test
> that identifies when the cached thumbnail no longer corresponds to the
> file and updates it.
It's an interesting question; I suspect the general answer isn't entirely
straight-forward (although it may appear to be so at first glance).
> >> The solution to this problem is to force thumbnails to be updated when out
> >> of date, by comparing a timestamp to the original file.
>
> >This won't fix the problem created by the steps you outlined above unless
> >you check the ctime (all other timestamps are not affected by rename
> >operations). However, even here you would need the thumbnail's ctime be set
> >to that of the original image when it was created to allow unambiguous
> >determination that a thumbnail is "out of date", and I don't think that's
> >possible.
>
> The thumbnail is created after the image file, so it seems to me that all
> you need to do is see if the thumbnail's ctime is older than the image file
> and if so, update it.
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.
> (I see no need to set the thumbnail's ctime to match the image file
> exactly.)
If this isn't done then I see no way to make a ctime test reliable, as noted
above.
> This already appears to be happening for the mtime, because when I write
> new exif data to an image file, I see the thumbnails being recreated in
> geeqie when it sees the image file changing. But this does not account
> for these file renaming operations, so switching to the ctime rather than
> the mtime, and looking for older timestamps would address the problem.
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. If one could set the thumbnail's ctime
(and I'm not sure this can be done in practice[*]) then testing ctime may
work (but I haven't analysed every use case, so there may still be issues).
[*] For example, note that "touch" can alter the access time or the
modification time. There's no mention in the manpage that it can
manipulate the ctime.
> >> ... but this particular problem is causing me quit a bit of difficulties
>
> >I am curious - what real-world scenario creates a situation along the lines
> >of the one you illustrated above? ...
>
> Actually, the sequence I described IS my real-world scenario. I have
> huge folders of unprocessed images from my camera. I start by taking a
> look at them in geeqie on one screen while I manipulate the image files
> in terminal windows on an adjacent screen using many scripts ...
As previously noted I misunderstood the original description of what you
were doing. I thought you were manipulating the thumbnail cache, not the
original images.
> I hope that explains things a but better.
Things are clearer for me now, yes. Thanks.
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
