Problem with new hard disk containing existing images
Locked
Problem with new hard disk containing existing images
 
|
I am currently using Digikam 1.9 and today I installed a new hard disk
for all my photos. I copied everything over outside of Digikam and then remounted the new hard disk in the same place as the old one was which contained the collections. The database was copied to the new hard disk as well. Just for the time being I also mounted the old hard disk at a new mount point so I could copy over anything I'd forgotten. On starting Digikam it promptly used the old hard disk at the new mount point without being told. I dont understand why since the new disk is mounted where the old one was. I use a complete hard disk for photos by the way which is an ntfs partition as it is shared with a dual boot XP install. Surely Digikam should have gone to the new hard disk in the original mount point! Stuart -- Website: http://www.stella-maris.org.uk or: http://www.broadstairs.org _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Hi Stuart T,
If your new harddisk has the same name as the old one (let´s say ¨photo¨, one is mounted as ¨photo¨ and the other as ¨photo_¨, you can see that in /media if that is your mountpoint. So maybe digikam did the right thing, it depends on which one is mounted first. If only the new drive has been mounted, digikam starts saying that it found the collection but that the disk id has changed, and it can and will read your new drive. regards, Rinus Op 09-10-11 18:09, Stuart T Rogers schreef: > I am currently using Digikam 1.9 and today I installed a new hard disk > for all my photos. I copied everything over outside of Digikam and > then remounted the new hard disk in the same place as the old one was > which contained the collections. The database was copied to the new > hard disk as well. Just for the time being I also mounted the old hard > disk at a new mount point so I could copy over anything I'd forgotten. > > On starting Digikam it promptly used the old hard disk at the new > mount point without being told. I dont understand why since the new > disk is mounted where the old one was. I use a complete hard disk for > photos by the way which is an ntfs partition as it is shared with a > dual boot XP install. > > Surely Digikam should have gone to the new hard disk in the original > mount point! > > Stuart _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Problem with new hard disk containing existing images
|
|
Rinus I do see in some ways what you are saying but quite honestly since
the disk is mounted at the same mount point within my user space as the old one I expected Digikam to just read the new one, find the database and the read the collections but it has actually read the new copy of the database and then updated all the collections to point to the old hard disk mount point which I do not believe should be correct operation. So now I have the new copy of the database pointing to all the old copies of the photographs. I expected it to read whatever the hard disk is mounted at that original mount point and get on with it, not to do what it has done and effectively corrupt the database with wrong pointers. It really should not care which hard disk is mounted but simply read the one which is. This makes it very difficult to upgrade a hard disk to a larger one and makes far more work then should be necessary. Stuart On 09/10/11 17:50, sleepless wrote: > Hi Stuart T, > If your new harddisk has the same name as the old one (let´s say > ¨photo¨, one is mounted as ¨photo¨ and the other as ¨photo_¨, you can > see that in /media if that is your mountpoint. So maybe digikam did the > right thing, it depends on which one is mounted first. If only the new > drive has been mounted, digikam starts saying that it found the > collection but that the disk id has changed, and it can and will read > your new drive. > regards, > Rinus > > Op 09-10-11 18:09, Stuart T Rogers schreef: >> I am currently using Digikam 1.9 and today I installed a new hard disk >> for all my photos. I copied everything over outside of Digikam and >> then remounted the new hard disk in the same place as the old one was >> which contained the collections. The database was copied to the new >> hard disk as well. Just for the time being I also mounted the old hard >> disk at a new mount point so I could copy over anything I'd forgotten. >> >> On starting Digikam it promptly used the old hard disk at the new >> mount point without being told. I dont understand why since the new >> disk is mounted where the old one was. I use a complete hard disk for >> photos by the way which is an ntfs partition as it is shared with a >> dual boot XP install. >> >> Surely Digikam should have gone to the new hard disk in the original >> mount point! >> >> Stuart > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users > -- Website: http://www.stella-maris.org.uk or: http://www.broadstairs.org _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
Op 09-10-11 19:10, Stuart T Rogers schreef:
> Rinus I do see in some ways what you are saying but quite honestly > since the disk is mounted at the same mount point within my user space > as the old one I expected Digikam to just read the new one, find the > database and the read the collections but it has actually read the new > copy of the database and then updated all the collections to point to > the old hard disk mount point which I do not believe should be correct > operation. > > So now I have the new copy of the database pointing to all the old > copies of the photographs. > > I expected it to read whatever the hard disk is mounted at that > original mount point and get on with it, not to do what it has done > and effectively corrupt the database with wrong pointers. It really > should not care which hard disk is mounted but simply read the one > which is. > > This makes it very difficult to upgrade a hard disk to a larger one > and makes far more work then should be necessary. > > Stuart > > On 09/10/11 17:50, sleepless wrote: >> Hi Stuart T, >> If your new harddisk has the same name as the old one (let´s say >> ¨photo¨, one is mounted as ¨photo¨ and the other as ¨photo_¨, you can >> see that in /media if that is your mountpoint. So maybe digikam did the >> right thing, it depends on which one is mounted first. If only the new >> drive has been mounted, digikam starts saying that it found the >> collection but that the disk id has changed, and it can and will read >> your new drive. >> regards, >> Rinus >> >> Op 09-10-11 18:09, Stuart T Rogers schreef: >>> I am currently using Digikam 1.9 and today I installed a new hard disk >>> for all my photos. I copied everything over outside of Digikam and >>> then remounted the new hard disk in the same place as the old one was >>> which contained the collections. The database was copied to the new >>> hard disk as well. Maybe just a weird and useless idea but if I understood correctly dk has changed the new copy of your db, hence it should be possible to start all over again with the old db... Rinus >>> Just for the time being I also mounted the old hard >>> disk at a new mount point so I could copy over anything I'd forgotten. >>> >>> On starting Digikam it promptly used the old hard disk at the new >>> mount point without being told. I dont understand why since the new >>> disk is mounted where the old one was. I use a complete hard disk for >>> photos by the way which is an ntfs partition as it is shared with a >>> dual boot XP install. >>> >>> Surely Digikam should have gone to the new hard disk in the original >>> mount point! >>> >>> Stuart >> >> _______________________________________________ >> Digikam-users mailing list >> [hidden email] >> https://mail.kde.org/mailman/listinfo/digikam-users >> > _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Problem with new hard disk containing existing images
|
|
Well I un-mounted the original copy and then started Digikam. I then got
messages for each collection saying that it was not on the disk with the correct UUID but had found it elsewhere, despite the fact that they were mounted at the same mount point!!! To my mind to use a UUID in the database to find one's collection is just daft. Noone but computers use UUIDs, it should simply use the original path and if it cannot find the photos then open a dialog for the user to select the correct path. I simply do not understand why on earth the UUID is used to identify collections, it makes it very awkward to replace a hard drive with the photos on for a larger one. Please change the way Digikam works so that it uses the actual path and not the UUID. Stuart On 09/10/11 18:26, sleepless wrote: > Op 09-10-11 19:10, Stuart T Rogers schreef: >> Rinus I do see in some ways what you are saying but quite honestly >> since the disk is mounted at the same mount point within my user space >> as the old one I expected Digikam to just read the new one, find the >> database and the read the collections but it has actually read the new >> copy of the database and then updated all the collections to point to >> the old hard disk mount point which I do not believe should be correct >> operation. >> >> So now I have the new copy of the database pointing to all the old >> copies of the photographs. >> >> I expected it to read whatever the hard disk is mounted at that >> original mount point and get on with it, not to do what it has done >> and effectively corrupt the database with wrong pointers. It really >> should not care which hard disk is mounted but simply read the one >> which is. >> >> This makes it very difficult to upgrade a hard disk to a larger one >> and makes far more work then should be necessary. >> >> Stuart >> >> On 09/10/11 17:50, sleepless wrote: >>> Hi Stuart T, >>> If your new harddisk has the same name as the old one (let´s say >>> ¨photo¨, one is mounted as ¨photo¨ and the other as ¨photo_¨, you can >>> see that in /media if that is your mountpoint. So maybe digikam did the >>> right thing, it depends on which one is mounted first. If only the new >>> drive has been mounted, digikam starts saying that it found the >>> collection but that the disk id has changed, and it can and will read >>> your new drive. >>> regards, >>> Rinus >>> >>> Op 09-10-11 18:09, Stuart T Rogers schreef: >>>> I am currently using Digikam 1.9 and today I installed a new hard disk >>>> for all my photos. I copied everything over outside of Digikam and >>>> then remounted the new hard disk in the same place as the old one was >>>> which contained the collections. The database was copied to the new >>>> hard disk as well. > > Maybe just a weird and useless idea but if I understood correctly dk has > changed the new copy of your db, hence it should be possible to start > all over again with the old db... > Rinus >>>> Just for the time being I also mounted the old hard >>>> disk at a new mount point so I could copy over anything I'd forgotten. >>>> >>>> On starting Digikam it promptly used the old hard disk at the new >>>> mount point without being told. I dont understand why since the new >>>> disk is mounted where the old one was. I use a complete hard disk for >>>> photos by the way which is an ntfs partition as it is shared with a >>>> dual boot XP install. >>>> >>>> Surely Digikam should have gone to the new hard disk in the original >>>> mount point! >>>> >>>> Stuart >>> >>> _______________________________________________ >>> Digikam-users mailing list >>> [hidden email] >>> https://mail.kde.org/mailman/listinfo/digikam-users >>> >> > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users > -- Website: http://www.stella-maris.org.uk or: http://www.broadstairs.org _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
I have had my own fights with it, but finaly know how to handle it. I
think the usage of the UUID is usefull for safety, not to mess up different db´s and probably for other reasons I don´t know about. If you think it is wrong and want to have it changed, I advise to make a bug report, that gives the best change for programmers attention. If you sofar not have it the way you intended, I might be able and always willing to help, I dealt with it several times before. Best regards Rinus Op 09-10-11 21:19, Stuart T Rogers schreef: > Well I un-mounted the original copy and then started Digikam. I then > got messages for each collection saying that it was not on the disk > with the correct UUID but had found it elsewhere, despite the fact > that they were mounted at the same mount point!!! > > To my mind to use a UUID in the database to find one's collection is > just daft. Noone but computers use UUIDs, it should simply use the > original path and if it cannot find the photos then open a dialog for > the user to select the correct path. > > I simply do not understand why on earth the UUID is used to identify > collections, it makes it very awkward to replace a hard drive with the > photos on for a larger one. > > Please change the way Digikam works so that it uses the actual path > and not the UUID. > > Stuart > > On 09/10/11 18:26, sleepless wrote: >> Op 09-10-11 19:10, Stuart T Rogers schreef: >>> Rinus I do see in some ways what you are saying but quite honestly >>> since the disk is mounted at the same mount point within my user space >>> as the old one I expected Digikam to just read the new one, find the >>> database and the read the collections but it has actually read the new >>> copy of the database and then updated all the collections to point to >>> the old hard disk mount point which I do not believe should be correct >>> operation. >>> >>> So now I have the new copy of the database pointing to all the old >>> copies of the photographs. >>> >>> I expected it to read whatever the hard disk is mounted at that >>> original mount point and get on with it, not to do what it has done >>> and effectively corrupt the database with wrong pointers. It really >>> should not care which hard disk is mounted but simply read the one >>> which is. >>> >>> This makes it very difficult to upgrade a hard disk to a larger one >>> and makes far more work then should be necessary. >>> >>> Stuart >>> >>> On 09/10/11 17:50, sleepless wrote: >>>> Hi Stuart T, >>>> If your new harddisk has the same name as the old one (let´s say >>>> ¨photo¨, one is mounted as ¨photo¨ and the other as ¨photo_¨, you can >>>> see that in /media if that is your mountpoint. So maybe digikam did >>>> the >>>> right thing, it depends on which one is mounted first. If only the new >>>> drive has been mounted, digikam starts saying that it found the >>>> collection but that the disk id has changed, and it can and will read >>>> your new drive. >>>> regards, >>>> Rinus >>>> >>>> Op 09-10-11 18:09, Stuart T Rogers schreef: >>>>> I am currently using Digikam 1.9 and today I installed a new hard >>>>> disk >>>>> for all my photos. I copied everything over outside of Digikam and >>>>> then remounted the new hard disk in the same place as the old one was >>>>> which contained the collections. The database was copied to the new >>>>> hard disk as well. >> >> Maybe just a weird and useless idea but if I understood correctly dk has >> changed the new copy of your db, hence it should be possible to start >> all over again with the old db... >> Rinus >>>>> Just for the time being I also mounted the old hard >>>>> disk at a new mount point so I could copy over anything I'd >>>>> forgotten. >>>>> >>>>> On starting Digikam it promptly used the old hard disk at the new >>>>> mount point without being told. I dont understand why since the new >>>>> disk is mounted where the old one was. I use a complete hard disk for >>>>> photos by the way which is an ntfs partition as it is shared with a >>>>> dual boot XP install. >>>>> >>>>> Surely Digikam should have gone to the new hard disk in the original >>>>> mount point! >>>>> >>>>> Stuart >>>> >>>> _______________________________________________ >>>> Digikam-users mailing list >>>> [hidden email] >>>> https://mail.kde.org/mailman/listinfo/digikam-users >>>> >>> >> >> _______________________________________________ >> Digikam-users mailing list >> [hidden email] >> https://mail.kde.org/mailman/listinfo/digikam-users >> > _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Problem with new hard disk containing existing images
|
|
In reply to this post by Stuart T Rogers
Am Sonntag, 9. Oktober 2011 schrieb Stuart T Rogers:
> Well I un-mounted the original copy and then started Digikam. I > then got messages for each collection saying that it was not on > the disk with the correct UUID but had found it elsewhere, despite > the fact that they were mounted at the same mount point!!! > > To my mind to use a UUID in the database to find one's collection > is just daft. Noone but computers use UUIDs, it should simply use > the original path and if it cannot find the photos then open a > dialog for the user to select the correct path. > > I simply do not understand why on earth the UUID is used to > identify collections, it makes it very awkward to replace a hard > drive with the photos on for a larger one. > > Please change the way Digikam works so that it uses the actual path > and not the UUID. Using the UUID is a fine idea for removable hard disks. So digikam can find it wherever it is mounted to. The mounting procedure may be different but the UUID will not change. Can you please take a look into your digikam.db with sqliteman? there must be a table called albumroots where all the roots of you configured albums are stored. There you can find the named UUID (at least I hope so). Changing it to the UUID of the new hard disk may solve your problem (a backup is a good idea of course). I never tested this myself thou. Martin > > Stuart > _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Problem with new hard disk containing existing images
|
|
In reply to this post by Rinus
Le 09/10/2011 21:33, sleepless a écrit :
> I have had my own fights with it, but finaly know how to handle it. I > think the usage of the UUID is usefull for safety, not to mess up don't forget many hard drives are removable, nowaday, so nobody know where they will be mounted next time. UUID is the better way to identify a drive. The result given by this thread is the proof it works :-)) jdd -- http://www.dodin.net http://www.youtube.com/user/jdddodinorg http://jdd.blip.tv/ _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Problem with new hard disk containing existing images
|
|
I haven't tried to move my albums, but it seems that this thread proves another thing - users need some easy option to migrate their albums, so that DK takes care of changing UUIDs instead of user manuals editing the database. That's a suggestion for future releases On Oct 10, 2011 7:19 AM, "jdd" <[hidden email]> wrote:
Le 09/10/2011 21:33, sleepless a écrit : _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Problem with new hard disk containing existing images
|
|
This problem have been already reproted in bugzilla, And
Marcel/Francesco who work ob DB interface are aware about it. Best Gilles Caulier 2011/10/10 Larry <[hidden email]>: > I haven't tried to move my albums, but it seems that this thread proves > another thing - users need some easy option to migrate their albums, so that > DK takes care of changing UUIDs instead of user manuals editing the > database. That's a suggestion for future releases > > On Oct 10, 2011 7:19 AM, "jdd" <[hidden email]> wrote: >> >> Le 09/10/2011 21:33, sleepless a écrit : >>> >>> I have had my own fights with it, but finaly know how to handle it. I >>> think the usage of the UUID is usefull for safety, not to mess up >> >> don't forget many hard drives are removable, nowaday, so nobody know where >> they will be mounted next time. >> >> UUID is the better way to identify a drive. The result given by this >> thread is the proof it works :-)) >> >> jdd >> >> -- >> http://www.dodin.net >> http://www.youtube.com/user/jdddodinorg >> http://jdd.blip.tv/ >> _______________________________________________ >> Digikam-users mailing list >> [hidden email] >> https://mail.kde.org/mailman/listinfo/digikam-users > > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users > > Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Problem with new hard disk containing existing images
|
|
Thanks for all the replies. I have now sorted it.
As has been said there needs to be some easier way of doing all this. 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. The problem I had was that the location was changed without any confirmation from me, this is simply unacceptable. Stuart On 10/10/11 07:48, Gilles Caulier wrote: > This problem have been already reproted in bugzilla, And > Marcel/Francesco who work ob DB interface are aware about it. > > Best > > Gilles Caulier > > 2011/10/10 Larry<[hidden email]>: >> I haven't tried to move my albums, but it seems that this thread proves >> another thing - users need some easy option to migrate their albums, so that >> DK takes care of changing UUIDs instead of user manuals editing the >> database. That's a suggestion for future releases >> >> On Oct 10, 2011 7:19 AM, "jdd"<[hidden email]> wrote: >>> >>> Le 09/10/2011 21:33, sleepless a écrit : >>>> >>>> I have had my own fights with it, but finaly know how to handle it. I >>>> think the usage of the UUID is usefull for safety, not to mess up >>> >>> don't forget many hard drives are removable, nowaday, so nobody know where >>> they will be mounted next time. >>> >>> UUID is the better way to identify a drive. The result given by this >>> thread is the proof it works :-)) >>> >>> jdd >>> >>> -- >>> http://www.dodin.net >>> http://www.youtube.com/user/jdddodinorg >>> http://jdd.blip.tv/ >>> _______________________________________________ >>> Digikam-users mailing list >>> [hidden email] >>> https://mail.kde.org/mailman/listinfo/digikam-users >> >> _______________________________________________ >> Digikam-users mailing list >> [hidden email] >> https://mail.kde.org/mailman/listinfo/digikam-users >> >> > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users > -- Website: http://www.stella-maris.org.uk or: http://www.broadstairs.org _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Problem with new hard disk containing existing images
|
|
In reply to this post by Stuart T Rogers
> Message: 6
> Date: Sun, 9 Oct 2011 22:38:57 +0200 > From: "Martin (KDE)" <[hidden email]> > To: [hidden email] > Subject: Re: [Digikam-users] Problem with new hard disk containing > existing images > Message-ID: <[hidden email]> > Content-Type: Text/Plain; charset="iso-8859-1" > > Am Sonntag, 9. Oktober 2011 schrieb Stuart T Rogers: >> Well I un-mounted the original copy and then started Digikam. I >> then got messages for each collection saying that it was not on >> the disk with the correct UUID but had found it elsewhere, despite >> the fact that they were mounted at the same mount point!!! >> >> To my mind to use a UUID in the database to find one's collection >> is just daft. Noone but computers use UUIDs, it should simply use >> the original path and if it cannot find the photos then open a >> dialog for the user to select the correct path. >> >> I simply do not understand why on earth the UUID is used to >> identify collections, it makes it very awkward to replace a hard >> drive with the photos on for a larger one. >> >> Please change the way Digikam works so that it uses the actual path >> and not the UUID. > > Using the UUID is a fine idea for removable hard disks. So digikam can > find it wherever it is mounted to. The mounting procedure may be > different but the UUID will not change. > > Can you please take a look into your digikam.db with sqliteman? there > must be a table called albumroots where all the roots of you > configured albums are stored. There you can find the named UUID (at > least I hope so). Changing it to the UUID of the new hard disk may > solve your problem (a backup is a good idea of course). I never tested > this myself thou. I had to do this when I got a new PC. My feeling is that requiring users of DK to do this when they get a new PC or get a bigger disk for their existing PC is simply unacceptable. People should be able to copy their DK database and pictures from one disk to another without having to address scary voodoo like this. Jon > > Martin > >> >> Stuart > _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Problem with new hard disk containing existing images
|
|
In reply to this post by Stuart T Rogers
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) 3) There is a heuristic which will detect when a hard-wired hard-disk was moved. At that moment, it will still ask for confirmation to change a collection's UUID. That means a plug-in replacement of a harddisk should be handled. If not, any bug reports or suggestions to improve detection of this situation are welcome 4) Even in the worst case - digikam thinks all old files are gone and all available files are new - there should be an almost complete recovery by recognizing identical files Marcel _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Problem with new hard disk containing existing images
|
|
In reply to this post by Stuart T Rogers
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 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 [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Stuart T Rogers
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 <[hidden email]>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 >[hidden email] >https://mail.kde.org/mailman/listinfo/digikam-users Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
|
|
In reply to this post by Jean-François Rabasse
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:
_______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Problem with new hard disk containing existing images
|
|
In reply to this post by Marcel Wiesweg
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) as I mentionned in my previous e-mail. Copy/paste of the evidence (my DK base and folders are on /data/digibase) -- jf@azrael:~> cd /data/digibase jf@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@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 _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Problem with new hard disk containing existing images
|
|
> > I agree there's no perfect solution for all cases. This is the point. As you already found out, digikam supports mount paths as well and uses them as fallback if no UUID is available. Additional form can be added in the future (for the SQLite case and the hard drives you mentioned, one could think about a "relative to location of database" identifier). We definitely need better identifiers for network storage, we may need alternate identifiers to make things work cross-platform. So we assume that the collection is located by some identifier, and that the files are available, as you say, by some file path. At runtime, we resolve the identifier to the current file path of the location. The path can also change at runtime (plug in a removable device) and is never written to the database. Marcel _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
Re: Problem with new hard disk containing existing images
|
|
I think the main point here is some way which the non-technical user
will be happy with to locate the collections and one which will not confuse. The user will expect to navigate to his/her collection via a path and will expect that path always to contain the collection. So it is fine to use the UUID as a reference to determine that something has changed but in my view it is imperative that IF something changes the user is immediately asked to confirm whether or not to use a new path. This did not happen in my case it simply opened the database and used the UUID to find the original collection which was still mounted but in a different place and updated the location in the database with the new path. Action like this is in my view totally unacceptable, if any change is detected (and it is right that it is) then the user must be immediately asked to confirm the change and if not wanted then to be able to select the correct location by path. In my case if this had been the case then I would not have had to start this thread. Stuart On 11/10/11 21:11, Marcel Wiesweg wrote: > >> >> I agree there's no perfect solution for all cases. > > This is the point. > > As you already found out, digikam supports mount paths as well and uses them > as fallback if no UUID is available. Additional form can be added in the > future (for the SQLite case and the hard drives you mentioned, one could think > about a "relative to location of database" identifier). We definitely need > better identifiers for network storage, we may need alternate identifiers to > make things work cross-platform. > > So we assume that the collection is located by some identifier, and that the > files are available, as you say, by some file path. At runtime, we resolve the > identifier to the current file path of the location. The path can also change > at runtime (plug in a removable device) and is never written to the database. > > > Marcel > _______________________________________________ > Digikam-users mailing list > [hidden email] > https://mail.kde.org/mailman/listinfo/digikam-users > -- Website: http://www.stella-maris.org.uk or: http://www.broadstairs.org _______________________________________________ Digikam-users mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-users |
«
Return to digikam-users
|
1 view|%1 views
| Free forum by Nabble | Edit this page |