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.
which libkexiv2 and exiv2 versions are installed? There's Help->components info. Can you reproduce the RAW files being touched when changing a tag?
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?
> 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.
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
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.
Still happens with 1.9.0.
We need feedback using a recent version. 2.0.0 RC is out, please test... Thanks in advance Gilles Caulier
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.
Javier, Do you see comment #8 ? Marc, This file still valid using digiKam 2.4 ? Gilles Caulier
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
This file still valid with digiKam 3.5.0 ? Gilles Caulier
New digiKam 4.11.0 is available : https://www.digikam.org/node/740 Can you reproduce the problem with this release ?
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