[Digikam-users] partial database info loss when folder moved to different partition.

[Brice Boyer]

Hello.!
I'm writing to report a strange problem. (using digikam 1.0 on latest beta
kde, running gentoo linux. not using kde wm though.)
There are several reiserfs partitions on my usb drive and one of them was
almost full (only 0.5GB remaining). So I moved within digikam (not using mv)
a folder to another collection on another partition. It is 27GB and 4K+
pictures.
These partitions are mounted with mount and custom rules (and digikam can't
recognise them as external storage and (why?)  it takes ages (about 6-7min
for only 60K photos) to start, even on a fresh quit without any
modifications to the disks).
Well... 3hrs later, the transfer was completed (with mv I get far far far
higher speeds of course). One problem was that around 1/5th of my jpgs were
showing wrong dates and no/partial tag/rating. Re-reading metadata from
image(s) worked because the info was stored in the tags... The other problem
is that most my nef (over 1K) lost their tags. Because I don't want digikam
to do bad things to them, I don't want tags written inside them. In case
there is such a problem, every nef has a small jpg (from camera) next to it
with tags stored inside. I could probably write a script to update the
database for all the nef+jpg according to the jpg tags...
Third problem : the folder images disapeared in both source and destination
folders. (most sources folders still contained non pictures elements such as
panorama data, rawstudio data,...) And this is a pain because it's a lot of
folder picture to re-set.

These are not important issues for me but I wanted at least to tell about
it... No such problems occured when moving a folder within the same
partition (or collection ?)

Since it's almost the first time I post to this list, let me say thank you
for this piece of software.

brice.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20091228/b1bad6db/attachment.html>