More issues with improper thumbnail creation

[jefferysmall]

ISSUE TYPE

• Bug Report

GEEQIE VERSION

Geeqie 1.7+git20220327-6d541232 GTK3

GTK3

OS / DISTRIBUTION

Xubuntu 22.04.2

SUMMARY

Geeqie get confused regarding thumbnail image and orientation under certain conditions

STEPS TO REPRODUCE

1: Start with a directory filled with many images of mixed horizontal and vertical images. When I take images off my camera, I will have a directory filled with files named dsc0001.jpg, dsc0002.jpg, etc. Usually there are 100-200 files.

2: View images with Geeqie and it creates thumbnails properly. Go through images and delete all those not wanted. Typically I'll delete 50-60% of the images as duplicates, bad, etc.

3: Close Geeqie or step up to a higher directory. Geeqie does not like it when files change rapidly while it is in that directory! (I've reported this before and wish it would handle this condition gracefully.)

4: Now I use a program I wrote to renumber all the files consecutively. For example, if dsc0004,jpg was deleted, then the next existing file will be renamed dsc0004.jpg and so on until all files are consecutively numbered.

5: Now step back into the directory and Geeqie starts rebuilding the thumbnails. Some of the new thumbnails are incorrect (don't match the actual image) but more often the horizontal or vertical orientation is now incorrect for some of the reconstructed image. It is as if Geeqie remembers the orientation of the previous image having that filename and uses it rather than checking the actual orientation of the new image. And yes, the meta-data for the Orientation and Camera Orientation are both correct.

6: I then manually touch(1) the file with the wrong image or orientation and usually Geeqie updates the thumbnail properly. What is very frustrating is that I can only touch one image at a time. If I touch two or more image with one command, Geeqie will only update the first image and not the remainder. What's going on here? Maybe Geeqie quits looking for changed files after the first one that it finds. It should be monitoring the directory for all changes.

7: One additional point. If I use my renumber program to change all of the filenames -- say moving dsc0001.jpg to dsc01.jpg and so on, then when Geeqie steps back into the directory it sees all new filenames and rebuilds the thumbnails with the proper image and orientation. This is why I believe that the program is caching some file info that it is using improperly when it re-examines a directory that only has some of the files renamed.

Hope all of this makes sense. This is very repeatable.

[caclark]

So far as I understand, the cache mechanism uses file path and file time. The thumbnail data is given the exact time of the original image file.

If you copy a modified file back to its original name, and set the file time to be the same as before, Geeqie will thinks its cached data is up-to-date.

Is this what is happening?

[jefferysmall]

No, I don't think so because any time a file is renamed, the access and change time should be updated. However, if the operation occurs quickly and the atime/ctime/mtime only have 1 second resolution, then it may look like these values have not changed.

I assume that ctime(3) is what is being checked here, not mtime(3). When I pull a bunch of files off my camera and load then into a directory in a batch, the a/c/m times are typically the same across all these copied files. After I delete various files and ten renumber, the mtime is going to remain the same for all the files but the ctime will change for those that are renamed.

If the ctime happens quickly, then the 1 second resolution might explain what is happening when the thumbnail image fails to update altogether during the renaming, but it doesn't explain the more common occurrence where the image updates but the orientation doesn't. This I cannot understand. If the thumbnail is regenerated, it should be done in accordance with the metadata of the current image. Am I missing something here?

One possibility is that Geeqie might check not only the ctime but also the file size to determine whether the file has actually changed in order to circumvent the 1 second resolution problem. This isn't foolproof since the new file sizes could also be identical to the old one, but it would be a low cost alternative to a checksum.

[caclark]

The time stamp that is checked is mtime.

[There is a section of the code in that area that is not understandable to me - it is when the cached data is newer than the image file. But I do not think this is relevant.]

[jefferysmall]

Well that could be a big part of the problem. Renaming files does not change the mtime.