[Digikam-devel] [Bug 215486] collection not found in location on disk with uuid (lvm volume)

[Marcel Wiesweg]

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





--- Comment #6 from Marcel Wiesweg <marcel wiesweg gmx de>  2009-11-22 11:42:52 ---

> The volume is an lvm2 one, though it matters not a bit, because I could have
> copied all my data to a new and bigger disk, then my uuid would also be
> different.
> 
> When I removed all the entries for AlbumRoots from the database, digikam told
> me it was unable to determine the uuid and if it was ok to use the pathname
> (which is perfectly fine with me).
> 
> I usually work remotely (ssh X tunnelling) I get this output:
>  virtual QStringList Solid::Backends::Hal::HalManager::allDevices()  error: 
> "org.freedesktop.DBus.Error.ServiceUnknown" 

It seems that HAL is broken on your installation. That explains why digikam
could not find the UUID of newly added collections and why it did not suggest
the new place of your collection in the first place.

(and no, we do not add extra handling when HAL is broken - for one we cannot
find out because Solid is cross-platform, and secondly it's a system service,
so it's the problem of distributions)


> To me it seems that in order to handle collections on temporary storage, the
> concept of uuid was added as a required authentication of a collection.
> However, there are lots of situations that can occur with perfectly
> non-temporary storage of collections that make the uuid change or unavailable
> (as in my case, probably).

The intention is to support storage on hard-disks, optical disks, all kinds of
pluggable USB storage devices, and - this is a different conceptual level -
network drives. For all of the former, the UUID is by far the best means of
identification, followed by volume label (can easily be the same for different
media) and mount path (maybe based on volume label on Linux, arbitrary on
Windows).

The UUID has a weakness when you repartition your harddisk and change the
filesystem type, but do not change the mountpoint. In this case digikam will
see that the old collection from hard-wired storage is missing, and there is a
new candidate with the same relative paths (under the mountpoint), and offer
you that as a candidate. Provided your HAL system services are not broken.


> If the database contains filename and exif-date linked with the unique database
> key used to store the tags and comments, I'd expect to get a 100% recovery in
> most cases.

Me too. Otherwise it's a bug ;-)

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