If image files are renamed, in the case of swapping names of
two files, dolphin loses track of the thumbnails...
STEPS TO REPRODUCE:
Create two images, "one.jpg" and "two.jpg", under Pictures. Open the
folder in Dolphin
Rename "two.jpg" to "twox.jpg". The file is renamed and the
thumbnail remains "as it should be"
Rename "one.jpg" to "two.jpg"...
The file is renamed but the thumbnail changes to that of the
"earlier" two.jpg. That is, both files appear with the same thumbnail
The thumbnail remains "as it was"
Was reported in a comment under Bug 432890, probably needs to
stand on its own.
One never knows, maybe some connection to bug 433116
Dolphin : 20.12.2
Plasma : 5.21.0
Frameworks : 5.79.0
Qt : 5.15.2
Files names are what it used as keys in the thumbnail cache.
If we want to solve this either we use other kind of keys like a hash of inode id / device id combination or we implement a special case in dolphin when renaming files, but that is tricky, or we implement some cache invalidation when files are moved / deleted.
(In reply to Méven Car from comment #1)
> Files names are what it used as keys in the thumbnail cache.
> ... like a hash of inode id / device id combination ...
Maybe the source node id can be held in a thumbnail xattr (and, if present, used for cross checking)
> ... or we implement some cache invalidation when files are moved / deleted.
Or maybe "when it is noticed".
It would definitely be nice if refreshing the panel sorted the thumbnails.
Isn't this stuff governed by a FreeDesktop.org spec? If there's an issue with the thumbnail keys, it might need to be fixed in the spec first.
Which talks about attributes in the PNG file: a couple being required:
plus some additional, including
If I poke around in my thumbnail PNG's, I see that these are being used. They would be enough to catch the issue I was having. The spec also leaves open the option of further 'X-' prefixed attributes.
There's a section covering detecting modifications:
If I delete all the thumbnail PNGs, touch one of the source images and rerun the test, the thumbnails work as they should.
If dolphin is checking the filename and modification time, that's not enough for my case. It also proved not enough for the test scenario (which is of course simplified!). Add in a check of the file size, and it would have been OK.
Posted a suggestion:
to suggest comparing the file size (in the cases it exists in the PNG metadata) as well as the modification time.
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/350
This (In reply to tagwerk19 from comment #6)
> Posted a suggestion:
> to suggest comparing the file size (in the cases it exists in the PNG
> metadata) as well as the modification time.
I would encourage you to fill a MR yourself, no coding involved, you can do it from the browser. https://gitlab.freedesktop.org/xdg/xdg-specs/-/blob/master/thumbnail/thumbnail-spec.sgml
In any case KIO does support time modification check but with a *second* precision meaning this bug can only happen when the two files share the same modification time modulo one second.
This will add file size to the cache validation check
Git commit b33307901f30ec8d724a7e424838165746563d06 by David Faure, on behalf of Méven Car.
Committed on 20/02/2021 at 11:40.
Pushed by dfaure into branch 'master'.
PreviewJob: consider file size for cache invalidation
M +2 -1 src/widgets/previewjob.cpp
(In reply to Méven Car from comment #8)
> ... I would encourage you to fill a MR yourself, no coding involved ...
Every day a learning day, how about
Yes, able to swap two files (that have the same timestamp) filenames.
That works, many thanks!
Plasma : 5.21.1
Frameworks : 5.80.0
Qt : 5.15.2