Version: svn 597473 (using KDE KDE 3.5.5) Installed from: SuSE RPMs OS: Linux An earlier bugreport 109517 on this matter was closed as being resolved, because the reporter couldn't reproduce it. By two occasions I met this bug also. The first one was when I renamed some files in an album from within Konqueror, and opening digiKam I noticed the loss of the tags of the renamed files, but not of the comment. Then further experiments showed also that moving imagefiles within the albumtree in digikam lead to the same loss of tags. Both appeared to be reproduceable.
As above mentioned jpeg-files do NOT lose the comment, but further testing reveals that nef-files do.
Caspar, Can you reproduce this problem with digiKam 0.9.0 final release? Gilles
I'm not using final release, but 0.9.1-svn614817. Tested: 1. a move within digiKam, both digiKam tags/comment and IPTC keywords/caption are preserved. 2. No loss of data with a move within Konqueror. 3. Renaming within digiKam works OK. 4. Renaming a file in Konqueror, preserved digiKam comment but lost the tags. IPTC keywords/caption were both preserved. Adding the tags again made the IPTC keywords show double. So there still isn't a one on one connection. Caspar.
I have an issue also related to the IPTC keywords being kept up to date (i probably should open a separate issue for it)... if you move a tag in the digikam Tags (left side) pannel (for example, changing the nesting of a tag to another tag), existing photos using that tag do not have IPTC keywords updated to reflect the new tag path. (I realise this could lead to big/long operations in some cases if tags used often are moved/altered ... but if one has chosen to save those tags in IPTC --- a very great feature! --- one wants to keep those IPTC tags in sync.)
point #4 in comment #3 and comment#4: I can confirm that ITPC keywords get doubled as tags are moved to different branches of the tag tree (as of digikam 0.9.1 on Kubuntu Feisty). This is mentioned in bug 141912
Caspar, This problem is fixed for you using last stable 0.9.3 ? Gilles Caulier
Hi. I am using KDE 3.5.9, digiKam 0.9.3 (final) on Kubuntu 8.10. I can reproduce this bug, so it appears to be not fixed. How do I reproduce: Prerequisite: image a.jpg is available add a tag to a.jpg add a geolocation to a.jpg Method 1: close digiKam, rename a.jpg to b.jpg, open digiKam --> digiKam complains about missing file on startup, tag on b.jpg is missing, but geolocation is still available Method 2: leave digiKam open, rename (on the filesystem, mv command) a.jpg to b.jpg, switch focus to digiKam (nothing happened), press F5 to refresh. --> tag on b.jpg is missing, but geolocation is still available There is something "special" to my setup: the image repository is on a NTFS disk: # mount | grep Bilder /dev/sda9 on /media/Bilder type fuseblk (rw,noexec,nosuid,nodev,noatime,allow_other,blksize=4096) Question: how may it be possible to "move" my image collection later (let's say I buy a new computer), i.e. how do I "export" all the DB contents, modify pathes etc. on the export dump, then reimport it back to another installation? (I.e. I am afraid of long time archiving data loss) Kind regards, Kay Drangmeister
Attempt of an explanation: Tags association is done within the digikam database. If you move/rename files around outside of digikam, then there is no way (currently!) for digikam to see how the moved/renamed file is connected with the original. That's where the corresponding tag association is lost. However, if you enable in digikams configuration: MetaData: Save image tags as "Keyword" tags/", Save image captions as embedded text, Save image rating as tags then they are stored in the file and recovered after a move/rename. Geolocation is different from these, as in 0.9.3 this is only stored in the file and not in the database (as it will be/is with 0.10). To move all the stuff to a different computer: - either enable writing (as above) - or copy all files, including the database itself. A full solution would be to store a unique hash/id for each image, which would allow to recognize images which are moved around, see https://bugs.kde.org/show_bug.cgi?id=125736 So shouldn't this bug here be considered as a duplicate of 125736? Best, Arnd
Thanks, Arnd. Please have a look into the digiKam manual (digikam_0.9.3.pdf), page 5 (9) "The Albums Missing Dialog", it says: "If you want to move folders around, and do not want to do this in digiKam, we suggest to do that while digiKam is running, so the database will be kept in sync and you do not lose any metadata". This (although about folders, not images) suggests that digiKam IS able to keep the FS and the DB in sync. Sorry for my assuming so. So for being safe, it would be very much suggested that *everything* is being stored in the image files, right? Is there any data that cannot be saved this way? I am currently "horrified" that some information is stored only in the DB and a simple move/rename can cause severe data loss. (I've got a big image base and are searching for a safe way to save it, i.e. any metadata must be exportable (xml preferred) in case there's another tool available to migrate to in say 20 years :-) Thanks, Kay
> FORWARDED from Gerhard Sorry for that misinstruction. The sentence should read 'move around images', I corrected it that way. Thanks Gerhard
Ok I got it. Think it's due to kmail-kde4, never happened before (I set the preferences to no-HTML, but it didn't help). When will kde4 be at the matureness of kde3?
I'm afraid this will take another year or even longer...
Caspar, This file still valid using digiKam 0.9.4 ? Gilles Caulier
(In reply to comment #13) > This file still valid using digiKam 0.9.4 ? Currently using 0.9.5-beta2 from svn. At your request tested again. Everything works fine. All the metadata is kept while moving and/or renaming in and out of digiKam. This seams to be solved. Do you expect me to mark this bug as fixed? Caspar.
Thanks Caspar, I confirm that it work too with 0.10.0 I close this file now. Gilles Caulier