SUMMARY: If digiKam reads a tag from the extended attributes of a file and the tag is modified, the change is seen in digiKam when the file modification time is changed and the screen refreshed. ... However If digiKam reads tags from the extended attributes of a file and the tags are subsequently removed, digiKam does not 'forget' the deleted tags (even after 'touching' the file and refreshing) In the same way, if tags are assigned within digiKam, saved to the Extended Attributes, and then deleted within digiKam and saved again, they are not removed from the xattr. STEPS TO REPRODUCE: On a system that supports Extended Attributes (such as Ext4, BTRFS) Tell digiKam that it should handle extended attributes, go to the "Settings / Configure digiKam / Metadata / Baloo" and set: Store metadata from digiKam in Baloo Read metadata from Baloo and under "... / Metadata / Behaviour / Write this information to the Metadata", select: Image tags Rating and also under "... / Metadata / Behaviour / Reading and Writing Metadata", select: Update file modification timestamp when files are modified Rescan file when files are modified Clear the selections under "... / Metadata / Advanced" for Tags and Ratings, on the basis that this is needed in order to write the tag/rating metadata back to the Extended Attributes Create new test image, add "mytag" as a tag with Dolphin or Gwenview, and check with getfattr: getfattr -d testfile.jpg # file: testfile.jpg user.xdg.tags="mytag" change the file modification time with "touch testfile.jpg" and check that digiKam sees the tag Delete the tag with Dolphin or Gwenview and confirm that it has gone, "touch testfile.jpg" to update the modification time and refresh digiKam OBSERVED RESULTS The testfile.jpg in digiKam still shows "mytag" EXPECTED RESULTS The tag should have gone... SOFTWARE/OS VERSIONS Neon Unstable DigiKam : 7.2.0 (build date 2021-03-06) Plasma : 5.21.80 Frameworks : 5.80.0 Qt : 5.15.2 Filesystem : Ext4
Often discussed, this is not a bug, but rather an intended behavior in the default settings. 1. Not all users (me for example) write their changes to the metadata or file attributes. If the metadata were read again, all new information in the DB would be deleted. 2. Therefore digiKam only adds new tags, labels, comments, etc., but does not remove any tags or the like. 3. If you want this, however, there is the option in the digiKam metadata settings to clean up the database when the metadata for the respective image is read in again. You then have to activate this option. 4. It is not necessary to touch the file date every time. You can also trigger the update of the image information via Album or Item-> Read metadata from image again. Maik
Another addendum. Of course digiKam merge all tags information, metadata + Baloo. If Baloo is the most important source for you, you should deactivate the reading of the tags in the advanced metadata settings by deactivating the checkbox. This can be done separately for writing and reading. Maik
Many thanks for the pointers! (In reply to Maik Qualmann from comment #1) > ... Not all users (me for example) write their changes to the metadata or > file attributes. If the metadata were read again, all new information in the > DB would be deleted. > ... If you want this, however, there is the option in the digiKam metadata > settings to clean up the database when the metadata for the respective image > is read in again. You then have to activate this option. I didn't trust myself to try this in my first time through. I've now given it a go, yes, that would do what I was "expecting". It is saying metadata from the images takes presidence over anything held in the internal DB and will overwrite it. A 'proper' multi-master synchronisation of settings would be a horrible job, you'd have to keep track of where each bit of information came from and which way you should sync it. No wish to rekindle old fires :-) > ... It is not necessary to touch the file date every time. You can also > trigger the update of the image information via Album or Item-> Read > metadata from image again. Oooh. I missed that. I didn't get further than a right click and a look down the context menu. I will also admit I assumed if an F5 refresh (or scan for new items) didn't do it, there wasn't an option. Options to "Reread" or "Write" metadata seem clear...
Re: the 'edge case', I wrote... (In reply to tagwerk19 from comment #0) > In the same way, if tags are assigned within digiKam, saved to > the Extended Attributes, and then deleted within digiKam and > saved again, they are not removed from the xattr. Digging deeper and being more careful: If I am modifying a tag (in digiKam) or removing one or more (but not all) tags and writing back to the xattr, the change is written If I remove all tags (in digiKam) and write back, the xattr are left untouched.
We can change that, we can remove the extended attributes completely ... Maik
Git commit bae01b9763d9e764bd2bcdb5b1c3be4f749e3393 by Maik Qualmann. Committed on 07/03/2021 at 09:39. Pushed by mqualmann into branch 'master'. also remove Baloo metadata FIXED-IN: 7.2.0 M +5 -15 core/utilities/extrasupport/filesindexer/baloowrap.cpp https://invent.kde.org/graphics/digikam/commit/bae01b9763d9e764bd2bcdb5b1c3be4f749e3393
(In reply to Maik Qualmann from comment #5) > ... we can remove the extended attributes completely ... So, that sounded scary. But the patch made sense. Just tested and the behaviour feels better - as in more predictable, fewer surprises. I think that's good, many thanks!