Bug 136206 - Losing tags after an move or rename of imagefiles
Summary: Losing tags after an move or rename of imagefiles
Alias: None
Product: digikam
Classification: Unclassified
Component: Tags-Engine (show other bugs)
Version: 0.9.1
Platform: openSUSE RPMs Linux
: NOR normal with 20 votes (vote)
Target Milestone: ---
Assignee: Digikam Developers
Depends on:
Reported: 2006-10-23 22:34 UTC by Caspar Maessen
Modified: 2022-01-22 14:02 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In: 7.6.0


Note You need to log in before you can comment on or make changes to this bug.
Description Caspar Maessen 2006-10-23 22:34:12 UTC
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.
Comment 1 Caspar Maessen 2006-10-23 22:58:47 UTC
As above mentioned jpeg-files do NOT lose the comment, but further testing reveals  that nef-files do.
Comment 2 caulier.gilles 2006-12-19 15:13:53 UTC

Can you reproduce this problem with digiKam 0.9.0 final release?

Comment 3 Caspar Maessen 2006-12-19 17:13:20 UTC
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 

Comment 4 Tim Middleton 2007-01-14 04:56:15 UTC
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.)

Comment 5 Congyi Wu 2007-06-21 03:16:30 UTC
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
Comment 6 caulier.gilles 2008-03-27 13:23:01 UTC

This problem is fixed for you using last stable 0.9.3 ?

Gilles Caulier
Comment 7 Kay Drangmeister 2008-06-27 16:19:54 UTC

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:

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

Comment 8 Arnd Baecker 2008-06-27 19:47:08 UTC
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

So shouldn't this bug here be considered as a duplicate of 125736?

Best, Arnd

Comment 9 Kay Drangmeister 2008-06-27 22:28:04 UTC
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 :-)

Comment 10 Andi Clemens 2008-07-23 11:09:49 UTC
> FORWARDED from Gerhard

Sorry for that misinstruction. The sentence should read 'move around images', I corrected it that way.


Comment 11 Gerhard Kulzer 2008-07-23 15:50:27 UTC
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?
Comment 12 Andi Clemens 2008-07-23 15:57:54 UTC
I'm afraid this will take another year or even longer...
Comment 13 caulier.gilles 2008-12-05 19:14:04 UTC

This file still valid using digiKam 0.9.4 ?

Gilles Caulier
Comment 14 Caspar Maessen 2008-12-06 15:51:02 UTC
(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?

Comment 15 caulier.gilles 2008-12-06 16:37:07 UTC
Thanks Caspar,

I confirm that it work too with 0.10.0

I close this file now.

Gilles Caulier