[Digikam-devel] [Bug 236730] Collection path is interpreted differently

dotCOMmie bugs at dotcommie.net
Tue May 18 16:29:42 BST 2010


https://bugs.kde.org/show_bug.cgi?id=236730





--- Comment #7 from dotCOMmie <bugs dotcommie net>  2010-05-18 17:29:42 ---
On 05/18/2010 11:19 AM, Marcel Wiesweg wrote:
>> I have 2 disk partitions home and root.
>> 9aea5987... is sda3
>> f9ac797c... is crypt_LUKS of sda3 which is /home/USERNAME
>
> Then the old database was perfectly all right, because f9ac + /media/pictures
> is on your system obviously /home/USERNAME/media/pictures
> Something must have changed on your system (broken HAL / Solid) so that this
> partition is no longer visible to digikam.
>

Thank you, I'll see if I can trace the bug there.

>
>>
>> Further more there seems to be dependance between image metadata (comments,
>> rating&  etc) and the album. If an album were to break (say recovering from
>> dead
>> disk) there does not seem to be a trivial way of rebuilding this short of
>> manually hacking away at the Album roots table. This seems like a great way for
>> a user to loose important data. It would be nice for digikam on creation of a
>> new album to check for image hashes and compare them to the existing ones (in
>> DB) and relink meta-data based on hashes.
>
> Of course, digikam checks the recorded hash and copies all metadata when it
> finds an identical file.
> Unfortunately, we rely on libexiv2 to get hashes over metadata, and the data
> libexiv2 returned to us changed in the past, so the hashes got different.
>

That makes sense, looks like convergence of several issues at play here. Is 
there a way in digikam to rebuild the table of hashes?

-- 
Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the Digikam-devel mailing list