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
Jonathan Woithe writes:
>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 befo
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
>
Jonathan Woithe writes:
Hi Jonathan:
>I'm not entirely sure how geeqie can be expected to detect this particular
>sequence of events, let along correct for it. What exactly do you think
>geeqie should do in the above case?
Geeqie sees that files are changing and updates accordingly. It should
He Jeffery
> In Geeqie v1.0 there is still a serious problem with thumbnail management.
> I am on a Solaris 10 SPARC system running the native Gnome desktop manager.
>
> To see the problem, create a new directory populated with 6 images named
> image_1.jpg, image_2.jpg, ..., image_6.jpg. Point g
In Geeqie v1.0 there is still a serious problem with thumbnail management.
I am on a Solaris 10 SPARC system running the native Gnome desktop manager.
To see the problem, create a new directory populated with 6 images named
image_1.jpg, image_2.jpg, ..., image_6.jpg. Point geeqie at it and let it
