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 geeqie at it and let it > create the thumbnails for the images. (I am using the shared thumbnail > location, so everything goes into ~/.thumbnails, but I do not think that > this has anything to do with the problem). Now, from the commandline, > remove image_2.jpg. Geeqie will update properly, dropping that image from > the display. Now, from the commandline, renumber the images as image_1.jpg > through image_5.jpg so that 3->2, 4->3, 5->4 and 6->5. > > What you will see is that the old thumbnails for image 2 through 5 will now > be reused, and all thumbnails will be incorrect for these pictures.
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? > 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. > 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. > Also, there needs to be an option ... that forces thumbnails to be > recreated in the current folder. That could be useful in some specific circumstances I guess. > ... 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? About the only thing I can think of which is vaguely similar is that some other application clobbers geeqie's thumbnails, but that's quite different to the renaming magic you describe (and could be detected by looking at the thumbnail mtime). In any case, aren't the shared thumbnail filenames generated with a hash, making such collisions rather unlikely (or am I thinking of something else - I'm no expert here)? 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
