Bug 246743

Summary: digiKam hate my image (file truncated to 0 byte after tagging)
Product: [Applications] digikam Reporter: Marc Aurel <marc-keyword-kdebug.e348b5>
Component: Tags-EngineAssignee: Digikam Developers <digikam-bugs-null>
Status: RESOLVED FIXED    
Severity: major CC: caulier.gilles, javier
Priority: NOR    
Version: 1.3.0   
Target Milestone: ---   
Platform: Unlisted Binaries   
OS: Linux   
Latest Commit: Version Fixed In: 5.1.0
Sentry Crash Report:

Description Marc Aurel 2010-08-04 23:44:54 UTC
Version:           1.3.0 (using KDE 4.4.95) 
OS:                Linux

Howdy, I'm a new user, trying to regain my freedom by evaluating digiKam as a replacement for Picasa. ;)

I'm working on a Ubuntu 10.04 system with Digikam 1.3 and KDE 4:4.4.92-0ubuntu1~lucid1~ppa1 from the kubuntu PPA, my image folders are located on a NFS server and were added to Digikam as local folders.


Reproducible: Didn't try

Steps to Reproduce:
I think this is what I did:
- I selected many raw images in a folder (CRW files)
- I tagged them with one keyword
- While the pictures were tagged, which took a while (!), I selected a different subset of images
- I tagged that new selection with another keyword and/or added a caption (I'm not sure anymore) while the first tagging process still was working, I noticed the thumbnails being refreshed

(I don't expect my result to be easily reproducible, though... looks like a race condition....)


Actual Results:  
One of the thumbnails turned into a "broken" image. Upon inspection, the underlying file proved to be 0 byte in size. The corrupted image was supposed to be tagged with both keywords, I think.



Expected Results:  
In the digiKam settings, section Metadata, the option "Write Metadata to RAW files (experimental)" was NOT enabled. Perhaps I'm misunderstanding something... why does digiKam touch raw CRW files during tagging when this option is disabled? 

So the expected result would have been an unchanged and uncorrupted image and instantaneous tagging only in the digiKam database.


There was no other imaging application running that could've accessed the folder simultaneously. And my systems don't have a history of spontaneous file combustions.

This could very well be considered a major bug, as it corrupted the user's data. ;)

Luckily, this didn't happen immediately after an import, so I had a backup of the image. It was a scary experience anyway, though.
Comment 1 Marcel Wiesweg 2010-08-17 11:53:16 UTC
which libkexiv2 and exiv2 versions are installed? There's Help->components info.

Can you reproduce the RAW files being touched when changing a tag?
Comment 2 Marc Aurel 2010-08-17 13:29:32 UTC
Hello Marcel, thanks for your interest in this bug.

According to Help / Components Information, the installed versions are:

LibKExiv2 1.1.0
LibExiv2 0.19

To verify whether the files are being touched, I used md5sum to get a hash of a CRW file, then added a tag to the image in digiKam (making sure I "applied" the change - the status line said "Writing metadata to files") and checked the hash again:

before: 7cbc560040ce396d5e0ce0362c92c382  CRW_0305.CRW
after:  7cbc560040ce396d5e0ce0362c92c382  CRW_0305.CRW

There goes my theory. But why would a RAW image file be truncated to zero bytes if it's not even touched?
Comment 3 Marcel Wiesweg 2010-08-23 10:07:06 UTC
> But why would a RAW image file be truncated to zero bytes
> if it's not even touched?

I'd like to know that as well ;-)
But that is very difficult to tell when we cannot reliably reproduce the problem.
Comment 4 caulier.gilles 2010-11-24 09:11:22 UTC
digiKam 1.6.0 is out:

http://www.digikam.org/drupal/node/550

Please update and check if this entry still valid.

Thanks in advance

Gilles Caulier
Comment 5 Javier Ruere 2011-04-07 22:20:41 UTC
I had a similar problem. I have my collection at one place but wanted to share some pics through Dropbox so I hardlinked them into a dir under the Dropbox dir.

After modifying tags, the files are truncated every time.

Tested this to a dir not watched by Dropbox and it happens just the same.
Comment 6 Javier Ruere 2011-04-07 22:21:56 UTC
Still happens with 1.9.0.
Comment 7 caulier.gilles 2011-07-06 11:21:20 UTC
We need feedback using a recent version. 2.0.0 RC is out, please test...

Thanks in advance

Gilles Caulier
Comment 8 Marcel Wiesweg 2011-07-11 17:03:38 UTC
Javier, 

1) we can forget about the dropbox and hardlink story, your files are 
reproducibly truncated to 0 bytes when applying a tag regardless where they 
are located?
2) Which file format?
3) Which libkexiv2/libexiv2 version? Go to Help components for details.
Comment 9 caulier.gilles 2011-12-16 12:18:22 UTC
Javier,

Do you see comment #8 ?

Marc,

This file still valid using digiKam 2.4 ?

Gilles Caulier
Comment 10 caulier.gilles 2012-06-22 08:51:56 UTC
Official digiKam 2.6.0 release is out since few days now :

http://www.digikam.org/drupal/node/656

Please, check if this entry still valid, or update report accordingly.

Thanks in advance.

Gilles Caulier
Comment 11 caulier.gilles 2013-11-06 16:42:11 UTC
This file still valid with digiKam 3.5.0 ?

Gilles Caulier
Comment 12 caulier.gilles 2015-06-30 08:07:03 UTC
New digiKam 4.11.0 is available :

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

Can you reproduce the problem with this release ?
Comment 13 caulier.gilles 2016-07-15 21:13:40 UTC
With digiKam 5.0.0, this problem is not reproducible.
I close this file now. Don't hesitate to re-open if necessary.
Gilles Caulier