[Digikam-users] Problem with new hard disk containing existing images

[Jean-François Rabasse]

On Mon, 10 Oct 2011, Marcel Wiesweg wrote:

> Some facts need to be mentioned in this thread:
>
> 1) Mount path does not work for removable devices, and fails completely cross-
> platform. UUID works for any directly accessible hard drive, and cross-
> platform if the non-Linux backends are properly implemented. It fails for
> network shares, no good solution here as of yet.
>
> 2) No mount path is stored in the database, that means nothing is changed in
> the database when you move your partition's mount path. Changing the
> collection entry still does not change any image entries (changing the
> "relative path" between the mount point and the immediate directory will
> trigger a rescan though)

Sorry to disagree, Marcel, but mount paths are stored in the database,
as I mentionned in my previous e-mail.

Copy/paste of the evidence (my DK base and folders are on /data/digibase)
--
   jf at azrael:~> cd /data/digibase
   jf at azrael:/data/digibase> sqlite3 digikam4.db
   SQLite version 3.7.7.1 2011-06-28 17:39:05
   Enter ".help" for instructions
   Enter SQL statements terminated with a ";"
   sqlite> select identifier, specificpath from albumroots;
   volumeid:?path=%2Fdata%2Fdigibase|/
   sqlite> .exit
   jf at azrael:/data/digibase>
--

(The base pathname is just URLencoded, %2F for '/')

And if I do the same thing on my laptop, I get volume identifier with
an UUID. And that's why my database can't be rsync'ed between the two
machines without being edited.

But it's a detail, I do cope with that as long as I'm happy to use DK.

** The interesting hint is that I've probably found why this behaviour
differences. UUID works only when the O.S. uses direct physical devices.
My laptop has a standard hard drive, with an UUID.
My desktop has two physical hard drives, both with 4 identical partitions,
but configured in a RAID 1 array.

And "logical" hard drives, e.g. /dev/md0 (which is a RAID 1 built from
physical /dev/sda1 and /dev/sdb1), don't have UUID !
A RAID array isn't a physical device, it's a pseudo device shown as a
disk by the RAID controler, (or mdadm software).

I've just done tests, declaring a new collection folder, and Digikam
says : "It is not possible on your system to identify the storage
medium of this path. It will be added using the file path as the
only identifier. This will work well for your local hard disk."

So, probably the reason why...
(Same as for network shares, btw, a network mounted filesystem
has no UUID).

Anyway, this conforts me when I believe UUIDs are not the definitive
solution for "application" software. An application program needs to
access data files, images files or other, to open them, read them.
And to open a file, whatever the function you use, open() or fopen(),
you need to supply a pathname, not an UUID :-)

And using UUIDs restricts to the cas of a user using only true physical
devices and always the same. (What if I have backup copies of folders
and DB on two different external USB drives ? Depending on which one
I plug, I won't get the same UUIDs though it the same directories tree.)

I agree there's no perfect solution for all cases. The better solution is,
as always, the one that covers the maximum of use cases.
If using DK with removable media is the most used configuration, so OK,
UUIDs may be used. But users should be warned the database is not
moveable, rsync'able, portable, across different machines or when
replacing a broken device by a new one (after data restoration).

Regards...
Jean-François