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

[Jean-François Rabasse]

Hello all...

On Mon, 10 Oct 2011, Stuart T Rogers wrote:

> I do not think that UUIDs should be externalised to the end user, this has 
> happened on Mandriva recently with USB sticks with no label which get mounted 
> at a default folder using the UUID. It did not go down well....
>
> I think the right way for Digikam to handle things like this should be to 
> check at start up to see if the UUID has changed and then ask the user to 
> confirm the location for the collections (assuming that the mount point has 
> not disappeared), at this time there should be an option for the user to 
> correct the location (if that is what they require). I do not believe that 
> any change should be made to the collection locations without prior 
> confirmation from the user.

I fully agree.

I had real problems with the way Digikam uses UUIDs. And it seems to be a
silly issue: I have two machines, a desktop, a laptop. On both machines
I have a mirror copy of my DK folders, both with exactly the same path.
I've called it /data/digibase and I have there the digikam4.db file and
images subdirectories.
If I look inside the DK database how the collection is handled, I get
on my desktop :
   sqlite> select identifier, specificpath from albumroots;
   volumeid:?path=%2Fdata%2Fdigibase|/
Ok, the pathname /data/digibase, URL encoded.

If I do the same thing on my laptop :
   sqlite> select identifier, specificpath from albumroots;
   volumeid:?uuid=4a91d85f-0774-4b71-8e7c-9d9c823f7eb0|/digibase
Ha ha, my laptop internal fixed hard drive is referenced by UUID.

The result is that I can't synchronise my two machines, folders and the
database file, without loosing the connexion. Digikam complains it
doesn't find the device. Of course, different disks on different machines
can't have the same UUID.

I solved the problem in a very dirty way. After a mirror copy between my
two machines, (I use rsync ...) I have a small script to hack the database
and updates. It works, but it's somewhat dirty.

Anyway, IMHO, I think UUIDs are a system level feature, and should never
be user level, or user applications level !
When Unix was designed, in the 1970s, people decided to have a 
uniformisation of disks devices and to show to users, and application,
only ONE files tree, starting at the / root directory.
(And that was a really good idea, at a moment where other O.S., e.g.
CP/M and later MS-DOS, had pathnames + devices, A:, B:, C:, etc.)

All what relates to devices mounts, mount points, hotplug mount, etc.
has to be handled under the user's sight. And under users applications
sight.

The problem with removable media is a system problem, not a user problem.
Linux supports that well. UUIDs are there to allow system level
recognition, not user level recognition.

I have a backup external USB disk, with 3 partitions on it, one is
Windows NTFS, the two other are Linux.
My /etc/fstab file contains the following three mount lines :
# -- Western Digital USB disk --
UUID=DE56EDEA56EDC37F   /usb/01 ntfs    defaults,nofail 0 0
UUID=7953c78d-96eb-45eb-882f-a909b6edebef /usb/02 ext3 defaults,nofail 0 0
UUID=51cda23b-eeca-4073-91a9-d8d0e44dc6d5 /usb/03 ext3 defaults,nofail 0 0

and when I plug my disk, I find my data always under /usb/01, /usb/02,
/usb/03, always the same things at the same place.
Applications or utility scripts (backup et al.) should only refer to the
Unix pathname, it's really a unique identifier because a Unix system
can have only one root directory /

The important reference to find a file is the absolute pathname, not
the /dev/disks/by-id/xxxxxxx or /dev/sdc4, or /dev/disks-by-uuid/xxxxxx
etc. Disk data is available to users and applications after mount, not
before. So let the system deal with that and show a uniformised
directories tree, and let users and application use that tree.

Have a good night :)
Jean-François