Tags manager "Sync Export" -> "Wipe all tags from database and read from images" is misleading. My understanding is "Wipe all tags from DB and then repopulate DB with data from image files", while subsequent messages (and actual behavior) indicated that it wipes the tags in files as well. The next message: "This operation will wipe all tags from database and will write changes to image metadata. Do you want to continue?" seems to be accurate. I managed to wipe my tags this way by not reading the second message carefully and trusting my understanding of the first one (good I had backup). Reproducible: Always Steps to Reproduce: 1. Open Tags Manager 2. Select "Sync Export" -> "Wipe all tags from database and read from images" 3. Confirm and wait Actual Results: Tags from DB and files are wiped Expected Results: I'm not sure what's the expected scenario, as I can imagine both ("Wipe tags from DB and files" and "Wipe tags from DB and restore from files") It seems that some ITPC tags were not wiped, after running "Re-read metadata from images" some tags reappeared.
Yep, I can reproduce this. I think it's because Metadata sync is enabled in menu. Will try to fix, I will add some code to disable tag sync when tags are wiped from database.
Git commit abd9f93fa2a22a1385f32094740466571a0587da by Veaceslav Munteanu. Committed on 03/03/2014 at 14:15. Pushed by munteanu into branch 'master'. Fixing bug 331695: Disable temporary wipe tags option to avoid accidental deletion of tags from image metadata M +3 -0 digikam/tags/tagsmanager/tagsmanager.cpp http://commits.kde.org/digikam/abd9f93fa2a22a1385f32094740466571a0587da diff --git a/digikam/tags/tagsmanager/tagsmanager.cpp b/digikam/tags/tagsmanager/tagsmanager.cpp index 4300c2b..47ba281 100644 --- a/digikam/tags/tagsmanager/tagsmanager.cpp +++ b/digikam/tags/tagsmanager/tagsmanager.cpp @@ -692,6 +692,9 @@ void TagsManager::setupActions() wipeAll->setHelpText(i18n("Delete all tags from database. " "Proceed with caution.")); + + /** BUG: Disabled temporary, will cause all tags from images to be lost **/ + wipeAll->setEnabled(false); connect(wrDbImg, SIGNAL(triggered()), this, SLOT(slotWriteToImg()));
Gilles, this is not the fix :)) I only disabled it (to avoid someone running to the same problem), until I will find a way to fix it :)
yes, i seen, but at least your commit must be CC in bugzilla entry for info Gilles
author Veaceslav Munteanu Sun, 09 Mar 2014 17:33:20 +0000 (19:33 +0200) committer Veaceslav Munteanu commit 2901c5564ccbbd6999ab8847c39870005c636fc4 Bug 331695: Rework TagsManager's wipe all tags to delete database only. Reread can be done via another menu entry. Small operations are more flexible http://quickgit.kde.org/?p=digikam.git&a=commit&h=2901c5564ccbbd6999ab8847c39870005c636fc4
Also, it's only me, or write tags do not purge old tags from images?
I think there are several use cases that behave differently... I think IPTC handling was written to not touch unknown tags (don't remove all tags, just those being changed). However in my experience with XMP the old tags are removed (this is empirical, not from code...). There are some strange scenarios where synchronization of metadata is not behaving the way I would expect, but tags in my files are quite a mess, so I haven't reported them as I think sometimes this could be the reason... Also I'm not 100% sure how some operations are supposed to work. Normally I keep metadata in sync with db. Normal tagging is straightforward, I add a tag, click apply, it's metadata is updated. 2 examples where it's not read/written: 1. When file is tagged outside digikam, it seems to detect the change (file seems to be reloaded), but tags are not updated until manually running "reread metadata..." 2. When tag is deleted (right click on tag, "delete tag"), it's gone from digikam but metadata is only written after manually triggering "write metadata" (my workaround: first manually remove the tag from all images - this will update the metadata, and only then really delete the tag itself)
This one has be FIXED. Other tags related problems are being discussed here: https://bugs.kde.org/show_bug.cgi?id=337688