After shuffling around disks, Digikam complains about unability to find a collection in existing (!!!) path. STEPS TO REPRODUCE 1. have /home/youruser/yourphotos set in digikam 2. change the uuid of the device where the directory resides (e.g. tune2fs -U ... for ext4fs) 3. start Digikam OBSERVED RESULT it reports error on start: Collection not found - digiKam The collection (Folder '/home/youruser/yourphotos' on the volume with the id "...") is currently not found on your system. Please choose the most appropriate option to handle this situation: [ ] The collection is located on a storage device which is not always attached. Mark the collection as a removable collection. [o] Take no action now. I would like to solve the problem later using the setup dialog EXPECTED RESULT No such nonsense, digikam should not rely on the underlaying layout of disks. SOFTWARE/OS VERSIONS Linux/KDE Plasma: 5.9.0 (available in About System) KDE Plasma Version: 5.14.3 KDE Frameworks Version: 5.52.0 Qt Version: 5.11.1 ADDITIONAL INFORMATION Going to settings => Database => Database Settings => browsing for the path and confirming /home/youruser/yourphotos again doesn't help Going to settings => Collections => Local Collections, I can only edit the name "Col. 0" but I see no path settings Note, this might be duplicate of bug 215486 but that deals with system upgrade. This isn't the case, this is solely about nonsensical insisting on UUID match.
2. change the uuid of the device where the directory resides (e.g. tune2fs -U ... for ext4fs) argh, scratch that! the UUID even did not change in my case, I was looking at the wrong place, what has changed is the UUID of / but not /home
Using a UUID is not a nonsense but a standard. How else should it be detected with removable drives, if it is the right drive. What do you think what is going on when digiKam destroys the database because it scans a wrong drive? One possible way to solve this problem would be to create a UUID and save it as a file in the root of the collection. Maik
(In reply to Maik Qualmann from comment #2) > Using a UUID is not a nonsense but a standard. considering the fact that digikam is the only software that failed, I'd doubt at least the "standard" part ... for example kmail via akonadi had no problem opening ~/.Mail after the disc shuffle > How else should it be detected with removable drives, > if it is the right drive. well, I believe you answer your own question: > One possible way to solve this problem would be to create a UUID and > save it as a file in the root of the collection. - if digikam already puts some metadata into that directory, it can put a signature file into it too in addition, some distros recently started mounting removable devices as /run/media/$USER/$UUID which makes the path pretty unique without having to handle the media id separately plus there is the volume label which might be (ab)used ... or simply asking the user to identify the medium if everything else fails > What do you think what is going on when digiKam destroys the database > because it scans a wrong drive? the database should not be destroyed in any case ... what if it identifies like a right drive but it appears empty due to some other problem? however, let's go back from generic discussion about removable media to what's important here: a) a problem appeared on *non-removable* media that I need fixed (and maybe other users would appreciate not running into it to :-)) - that problem should not have happened in the first place b) I see no way how to convince digikam that it should use that path - in addition to looking into application settings, before finding out my mistake that different UUID changed than I thought, I've even tried to fiddle with sqlite like UPDATE AlbumRoots SET identifier="volumeid:?uuid=..." WHERE id=1; where I had put uuid of the / device, then I also tried if it can just get ignored if I set it to NULL, but nothing helped
Git commit ceac0f1f71118e9b24316320ec1ab98237125f2b by Maik Qualmann. Committed on 07/12/2018 at 20:48. Pushed by mqualmann into branch 'master'. add button to update an existing collection to the new drive or path This satisfies a long-standing desire of many users to easily adapt an existing collection to a new drive. FIXED-IN: 6.0.0 M +2 -1 NEWS M +1 -0 core/libs/database/collection/collectionmanager.h M +89 -3 core/libs/database/collection/collectionmanager_location.cpp M +7 -0 core/libs/database/coredb/coredb.cpp M +7 -0 core/libs/database/coredb/coredb.h M +290 -36 core/utilities/setup/collections/setupcollectionview.cpp M +17 -5 core/utilities/setup/collections/setupcollectionview.h https://commits.kde.org/digikam/ceac0f1f71118e9b24316320ec1ab98237125f2b
cooooool - thanks! (now I just hope it'll work for me and the update will make it out soon :-))
I rebuild this morning, all digiKAm 6.0.0-beta3 including the Maik fixes. You can test with these files : https://files.kde.org/digikam/ Warning : 6.0.0 database schema introduce changes which will become incompatible with 5.9.0. Make a database backup before, else we will not be able to go back to 5.9.0 later. Best Gilles Caulier
(In reply to caulier.gilles from comment #6) > You can test with these files : > > https://files.kde.org/digikam/ thanks, but I don't see the sources there ... looking at the schedule https://www.digikam.org/documentation/releaseplan/ 6.0 should be out today ... looks like we're a bit behind :-(
ok, I cloned from git and created the tarball ... now I'm missing translations, and it crashes => bug 402496 but while I got the same message on startup, going to settings I could re-read the collection directory and now it seems to work fine, thanks!
> add button to update an existing collection to the new drive or path I also have collections which are broken due to volume id change. Although debian doesn't have a 6.x version, I am trying 6.2.0 from Nixpkgs. I have looked for this new button in settings->configure digikam->collections (and elsewhere), but I can't seem to find it. Is the button in 6.2.0? Can you tell where to look? I agree with this bug's author and others that if a collection is defined by a file path, then it shouldn't depend on a volume ID, and so this bug report should not be closed. Thank you for adding a button as a work-around.
The button is located in the digiKam settings for the collection next to the button for deleting a collection. It is now very easy to update a path and thus the drive UUID. There are many reasons not only to use the path as an identification. If you really want to add the collection only with path, use a network collection. Closed... Maik
(In reply to Maik Qualmann from comment #10) > The button is located in the digiKam settings for the collection next to the > button for deleting a collection. Thanks for a quick reply! I don't have a button for deleting a collection or for changing the UUID. Just a white line with the name of the collection. I searched for the delete button in the docs, and if I hover the mouse around at that location on the white line, I see a pair of "phantom" blue squares while hovering, but no tool text or anything. I presume these are the missing buttons. Perhaps grabbing 6.2.0 from Nixpkgs has left me without icons for those buttons.
Created attachment 125270 [details] Screenshot Installing the Breeze Icon Theme is important for digiKam, because only this contains all the necessary icons for digiKam. See the screenshot. Maik