[Digikam-devel] Re: use of uuid in database

Roger Larsson roger.larsson at e-gatan.se
Tue May 3 12:12:09 BST 2011


Following up on my own message
Noticed that digikam scanned the complete /home

sqlite3 digikam4.db
update AlbumRoots set identifier='volumeid:?path=/home'||specificPath;
.quit

Works better but it feels like I loose tags - but not all in a folder - 
strange...
(should specificPath be cleared?)

Files were copied with
 cp -a
so file dates are the same - but new disk uses ext4, old used ext3...

/RogerL

On Tuesday 03 May 2011, Roger Larsson wrote:
> Hi,
> I recently bought a new hard drive copied all my /home stuff to it.
> Used the old disk as a backup
> - mounted in /mnt/backup
> - moved all files on it into /mnt/backup/home (as I will use it to backup
> /etc too)
> 
> This breaks digikam badly all tags disapear... but it could have been
> worse...
> 
> I have come to the conclusion that this is the root cause of my problems is
> because of the uuid. It could have been worse...
> If I simply had mounted the old disk as /mnt/backup it would have "worked"
> with all new files going to the "backup" disk...
> 
> Tried the trick below - yea, I had backups of digikam4.db!
> 
> > sqlite3 digikam4.db
> 
> update AlbumRoots set identifier="volumeid:?path=/home" where
> identifier="volumeid:?uuid=xxxxxxxx";
> .quit
> 
> (Actually not the "were..." since all my folders were located under /home)
> 
> But starting digikam causes a rescan... (might be because I upgraded to
> OpenSuSE Tumbleweed, using digikam 1.9)
> It is still scanning... but I am worried...
> 
> /RogerL
> 
> > > On Wednesday 13 August 2008 21:36:38 gerhard at mail.morbitzer.de wrote:
> > > > I have a problem with 0.10b3 where digikam is innocent:
> > > > I use btrfs 0.16 (linux equivalent of zfs) for my /home. btrfs is not
> 
> yet
> 
> > > > supported by volume-id0, so the UUID is not detected by the system
> > > > and digikam. And digikam 0.10 doesn't work with my image folder as
> > > > it stores the UUID in the DB collection path, 0.9.5 works perfectly.
> > > > 
> > > > Is there any trick to convince digikam to accept my drive?
> > > > 
> > > > Gerhard
> > > 
> > > I found a solution to my problem. Marcel has built-in three different
> > > ways of uniquely identifying a collection
> > > - uuid
> > > - path
> > > - hash on root folder (for CD/DVD)
> > > 
> > > The solution in my case is:
> > > - to have a backup of digikam4db (otherwise as soon as you open digikam
> 
> the
> 
> > > DB wil be corrupted with the new uuid-less drive)
> > > - to open digikam4.db and change in the AlbumRoots the Identifier from
> > > volumeid:?uuid=xxxxxxxxxxxxxxxxxxxxxxxxxxx  to  volumeid:?path=/home
> > > (if /home is the the volume of the uuid-less drive.
> > > - that's it, start digikam 0.10 and all is there.
> > 
> > We have definitely to solve this in code, so that a path identifier is
> > used
> 
> if
> 
> > the uuid is invalid. These are just situations that have never been
> > tested.
> 
> I
> 
> > will look at t he code, where something may go wrong and probably ask you
> > some questions when I find some time. Currently I'm in Sydney and need to
> 
> see
> 
> > the city :-)
> > 
> > Btw, similar problems may occur when someone starts to use network file
> > systems as album roots. There are still some open ends and it needs
> > testing.
> > 
> > Marcel
> 
> _______________________________________________
> Digikam-devel mailing list
> Digikam-devel at kde.org
> https://mail.kde.org/mailman/listinfo/digikam-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/digikam-devel/attachments/20110503/908e6b17/attachment.html>


More information about the Digikam-devel mailing list