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

[simon at margo.student.utwente.nl]

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





--- Comment #4 from  <simon margo student utwente nl>  2009-11-21 20:52:30 ---
> Nothing is said about loss of database information.
> Please report upgrade problems

Technically, the database lost no information, because the file digikam4.db was
still there, containing the information (AFAICT).

The upgrade problem is that I was confronted with a newer version of digikam
and I "lost" my entire "collection" due to some error regarding the uuid of the
disk on which my collection is stored.

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).


> 
> > - neither action proposed is or could be appropriate
> > - the reference to the setup dialogue is misleading, since the actual path to the
> > configuration in digikam is elsewhere.
> 
> ??

The error refers to the "setup dialogue", the actual path is menu -> Settings
-> Configure Digikam -> Collections, if I understand correctly.


> > - the actual database is still there _and_ is the cause of the problem, because
> > it contains bad information about paths and volume-ids that earlier versions of
> > digikam have put there themselves.
> 
> The database did not change. Probably your partitions and or filesystems
> changed.
> Please post the output of "solid-hardware list details"

I usually work remotely (ssh X tunnelling) I get this output:
 virtual QStringList Solid::Backends::Hal::HalManager::allDevices()  error: 
"org.freedesktop.DBus.Error.ServiceUnknown" 

> 
> > The path I had was of the form:
> > 6034d5dd-65c5-40a6-a231-d20f1e4e02a7
> > (though probably volumeid:?uuid=6034d5dd-65c5-40a6-a231-d20f1e4e02a7)
> 
> That is how it should be.
> 
> > 
> > And it should be:
> > volumeid:?path=%2Fhome%2Fsimon%2FPhotos
> > And a / in the next field, instead of /home/simon/Photos
> 
> No it should not be like this. It works like this, it can be like this if you
> have reason.

Well, whether or not this is right or wrong according to the current
implementation or intention, I would like to argue that this way of referring
to "collections" is error prone, due to uncaught assumptions (as far as I
understand the intention, of course).

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).

If my assumption is correct, I would suggest to change the behaviour of digikam
to take the uuid as a hint and rely mostly on the pathname. If a mismatch is
found in the uuid, or the stored collection on disk (the actual image files),
then it might be that you're dealing with a (different) temporary storage
device, rather than a permanently collected storage device. The latter being
the common use-case, I presume.

In modern Linux systems, the pathname is usually /media/<volume-label> anyway,
so it might very well be that the problem is commonly solved that way, without
needing something as arbitrary as a uuid. (It's not like you can see from the
uuid what kind of disk you're dealing with)

And furthermore, even if something seems to be wrong, it would definitely be
helpful if digikam was able to "import" the old database for the meta-data of
the files. 

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.

I hope I've cleared up the situation!

/Simon

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