<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi,<br>
By sending from a different device my message has escaped the tread.
So once again and a bit more specific:<br>
<pre wrap="">Yesterdays message:
Not that I would say there is no problem, I agree completely on that even if it is unsolvable due to multi platform issues, but to show a workaround without hacking the db, for which not only me but probably lots of us are not smart enough.
The first time you copy your db and pictures to your other computer, you have to do a complete (re)scan, but after that first time you can rsync and digikam does never complain. I work for six months or so in the same laptop/desktop situation without any trouble.
to be a bit more specific
The drive on the desktop is internal, the one on the laptop external. Both mounted as media/FOTO and all collectioned added as local collections.
I rsync in both directions whichever one is needed. After that the updated dk says at startup: the collection is still available, but the identifier changed¨ and all I have to do is click ok for each collection.
In fact one of my greatest fears is that I will no longer be able to do so after some update. That would make digikam useless to me.
Best regards,
Rinus
</pre>
<br>
<br>
Op 10-10-11 23:08, Jean-François Rabasse schreef:
<blockquote
cite="mid:alpine.LNX.2.00.1110102233170.10008@azrael.victoria.net"
type="cite">
<br>
Hello all...
<br>
<br>
On Mon, 10 Oct 2011, Stuart T Rogers wrote:
<br>
<br>
<blockquote type="cite">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....
<br>
<br>
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.
<br>
</blockquote>
<br>
I fully agree.
<br>
<br>
I had real problems with the way Digikam uses UUIDs. And it seems
to be a
<br>
silly issue: I have two machines, a desktop, a laptop. On both
machines
<br>
I have a mirror copy of my DK folders, both with exactly the same
path.
<br>
I've called it /data/digibase and I have there the digikam4.db
file and
<br>
images subdirectories.
<br>
If I look inside the DK database how the collection is handled, I
get
<br>
on my desktop :
<br>
sqlite> select identifier, specificpath from albumroots;
<br>
volumeid:?path=%2Fdata%2Fdigibase|/
<br>
Ok, the pathname /data/digibase, URL encoded.
<br>
<br>
If I do the same thing on my laptop :
<br>
sqlite> select identifier, specificpath from albumroots;
<br>
volumeid:?uuid=4a91d85f-0774-4b71-8e7c-9d9c823f7eb0|/digibase
<br>
Ha ha, my laptop internal fixed hard drive is referenced by UUID.
<br>
<br>
The result is that I can't synchronise my two machines, folders
and the
<br>
database file, without loosing the connexion. Digikam complains it
<br>
doesn't find the device. Of course, different disks on different
machines
<br>
can't have the same UUID.
<br>
<br>
I solved the problem in a very dirty way. After a mirror copy
between my
<br>
two machines, (I use rsync ...) I have a small script to hack the
database
<br>
and updates. It works, but it's somewhat dirty.
<br>
<br>
Anyway, IMHO, I think UUIDs are a system level feature, and should
never
<br>
be user level, or user applications level !
<br>
When Unix was designed, in the 1970s, people decided to have a
uniformisation of disks devices and to show to users, and
application,
<br>
only ONE files tree, starting at the / root directory.
<br>
(And that was a really good idea, at a moment where other O.S.,
e.g.
<br>
CP/M and later MS-DOS, had pathnames + devices, A:, B:, C:, etc.)
<br>
<br>
All what relates to devices mounts, mount points, hotplug mount,
etc.
<br>
has to be handled under the user's sight. And under users
applications
<br>
sight.
<br>
<br>
The problem with removable media is a system problem, not a user
problem.
<br>
Linux supports that well. UUIDs are there to allow system level
<br>
recognition, not user level recognition.
<br>
<br>
I have a backup external USB disk, with 3 partitions on it, one is
<br>
Windows NTFS, the two other are Linux.
<br>
My /etc/fstab file contains the following three mount lines :
<br>
# -- Western Digital USB disk --
<br>
UUID=DE56EDEA56EDC37F /usb/01 ntfs defaults,nofail 0 0
<br>
UUID=7953c78d-96eb-45eb-882f-a909b6edebef /usb/02 ext3
defaults,nofail 0 0
<br>
UUID=51cda23b-eeca-4073-91a9-d8d0e44dc6d5 /usb/03 ext3
defaults,nofail 0 0
<br>
<br>
and when I plug my disk, I find my data always under /usb/01,
/usb/02,
<br>
/usb/03, always the same things at the same place.
<br>
Applications or utility scripts (backup et al.) should only refer
to the
<br>
Unix pathname, it's really a unique identifier because a Unix
system
<br>
can have only one root directory /
<br>
<br>
The important reference to find a file is the absolute pathname,
not
<br>
the /dev/disks/by-id/xxxxxxx or /dev/sdc4, or
/dev/disks-by-uuid/xxxxxx
<br>
etc. Disk data is available to users and applications after mount,
not
<br>
before. So let the system deal with that and show a uniformised
<br>
directories tree, and let users and application use that tree.
<br>
<br>
Have a good night :)
<br>
Jean-François<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Digikam-users mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Digikam-users@kde.org">Digikam-users@kde.org</a>
<a class="moz-txt-link-freetext" href="https://mail.kde.org/mailman/listinfo/digikam-users">https://mail.kde.org/mailman/listinfo/digikam-users</a>
</pre>
</blockquote>
<br>
</body>
</html>