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

[sleepless]

Hi,
By sending from a different device my message has escaped the tread. So 
once again and a bit more specific:

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




Op 10-10-11 23:08, Jean-François Rabasse 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-users/attachments/20111011/1d58bd7f/attachment.html>