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

[Rinus]

Hi,
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. 
Good night,

Or if you happen to be on the other side of the earth: have a nice day.

Rinus

Jean-François Rabasse <jean-francois.rabasse at wanadoo.fr>schreef:

>
>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
>_______________________________________________
>Digikam-users mailing list
>Digikam-users at kde.org
>https://mail.kde.org/mailman/listinfo/digikam-users