Bug 347348 - Moving a directory loses metadata in database associated with .cr2 raw files
Summary: Moving a directory loses metadata in database associated with .cr2 raw files
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Applications
Component: Database-Files (show other bugs)
Version: 4.9.0
Platform: openSUSE Linux
: NOR critical
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-06 22:15 UTC by Kenneth Ingham
Modified: 2017-07-26 06:58 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.13.0
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kenneth Ingham 2015-05-06 22:15:04 UTC
With two versions of digikam running, I move a directory(folder) from one location to another.  The files, including the metadata sidecar files are properly moved.  However, after the move, the .cr2 raw files no longer show any metadata.  Looking in the sidecar file, I can see the tags, copyright, caption, etc.  However, they do not show up with the thumbnails nor in the metadata side panel.  Selecting read metadata from file to database does nothing (shouldn't it try reading the sidecar?).

 JPEG, TIFF, and other files where the metadata is stored in the file itself seem to move OK; I am guessing that scanning a new directory picks it up.  However, since digikam is doing the moving, shouldn't it know to update the database as it moves the files?  And, it should be able to read metadata from the sidecar in any case.

Reproducible: Always

Steps to Reproduce:
1. Add metadata to a .cr2 file with sidecar storage.
2. Move the folder somewhere else.
3. Look at the new location.

Actual Results:  
All raw files have lost metadata, but JPEG, TIFF, and other files where the metadata is stored in the file itself move OK.

Expected Results:  
Metadata stored in the database moves with the files.  Metadata in sidecar files should be able to be loaded into the database.

Possibly relevant packages:
digikam-4.9.0-1.1.x86_64
digikam-doc-4.9.0-1.1.noarch
digikam-debuginfo-4.9.0-1.1.x86_64
kipi-plugins-geolocation-4.9.0-1.1.x86_64
kipi-plugins-lang-4.9.0-1.1.noarch
kipi-plugins-acquireimage-debuginfo-4.9.0-1.1.x86_64
kipi-plugins-4.9.0-1.1.x86_64
libkipi-devel-14.12.3-16.1.x86_64
kipi-plugins-geolocation-debuginfo-4.9.0-1.1.x86_64
kipi-plugins-acquireimage-4.9.0-1.1.x86_64
kipi-plugins-debuginfo-4.9.0-1.1.x86_64
libkipi11-14.12.3-16.1.x86_64
Comment 1 Kenneth Ingham 2015-05-06 22:15:36 UTC
This is related to, but different from 326112.
Comment 2 Maik Qualmann 2015-05-07 06:10:47 UTC
The problem is not reproducible in a short test. All metadata from sidecar are displayed after moving the CR2 files. If the images are stored on a network or local drive?

Maik
Comment 3 caulier.gilles 2015-05-07 06:19:16 UTC
Same here : not reproducible with files in local collection.

Gilles Caulier
Comment 4 Kenneth Ingham 2015-05-07 16:01:14 UTC
This is bizarre.  It happened yesterday.  Today, I cannot reproduce it.  I will keep experimenting to figure out what the specific circumstances are.
Comment 5 Kenneth Ingham 2015-05-18 15:00:50 UTC
It just happened again. 

OK, this is weird.  The data was not showing up, and then when I went to gather additional data for this update, it was there.  Is there a noticeable delay (at least a couple of minutes) between moving and the data showing up in the database?
Comment 6 caulier.gilles 2015-05-18 15:09:27 UTC
It can be. This depend of many factor.

I think the most important is DB file fragmentation, especially if file size is big, refer to a huge collection of image, and is located to an hard drive.

Personalty, i use SSD to host BD (and also photo : 1Gb device). Time responsive is very very fast. I manage over 250Gb of photo.

Note : It miss a tool to check DB integrity in digiKam. There is a file in bugzilla about this topic.
Gilles
Comment 7 caulier.gilles 2015-05-18 15:10:43 UTC
It can be a good indicator to evaluate the CPU/Memory overload when it's happen. Perhaps something take a while and slow down DB on your system.

Gilles Caulier
Comment 8 caulier.gilles 2015-06-24 16:16:44 UTC
New digiKam 4.11.0 is available :

https://www.digikam.org/node/740

Can you reproduce the problem with this release ?

Gilles Caulier
Comment 9 caulier.gilles 2015-08-17 11:26:20 UTC
digiKam 4.12.0 is out :

https://www.digikam.org/node/741

We need a fresh feedback using this release please...
Thanks in advance.

Gilles Caulier
Comment 10 Kenneth Ingham 2015-08-24 15:32:37 UTC
I do not see this problem with 4.11.

Thanks.