Here the problematic configuration: - the album is stored in the home directory, say ~/Photos; - /home is a standalone partition; - another directory of the home (say ~/Shared) is bind mounted in order to be accessed by others. The command used is 'mount --bind ~/Shared /work/Share1' - /work is also a standalone partition. With this configuration, digikam does not find the album when started and shows nothing. Worst, after removing the bind mount and restarting digikam, it shows the photos but *all the data are lost* (titles, legends, labels, etc...). We can guess that something is wrong since it takes a while to start, like when it sees a directory for the first time. Reproducible: Always Expected Results: The album should be found in every situation, and maybe a backup done when it is not found, otherwise you lost everything.
I can confirm this bug. I am experiencing the same problem after setting up a bind mount.
I played a little with bind mount and can not reproduce this issue. Which album directories were added in digiKam? Following the example above ~/Photos and ~/Shared. Right? Maik
In my configuration, my digikam root album is the root of my user home directory, ~. The bind connects a subdirectory under my home directory, say ~/foo, to a location on another partition, /var/lib/foobar. Then it is remounted read-only. (Actually, I'm using lvm, so they are lvm partitions, not physical partitions.) /etc/fstab: /home/cdoe/foo /var/lib/foobar none bind 0 0 /etc/rc.local: mount -o remount,ro /var/lib/foobar $> mount /home/cdoe/foo on /var/lib/foobar type none (ro,bind) On 04/07/2015 03:56 PM, Maik Qualmann wrote: > https://bugs.kde.org/show_bug.cgi?id=345391 > > Maik Qualmann <metzpinguin@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |metzpinguin@gmail.com > > --- Comment #2 from Maik Qualmann <metzpinguin@gmail.com> --- > I played a little with bind mount and can not reproduce this issue. Which album > directories were added in digiKam? Following the example above ~/Photos and > ~/Shared. Right? > > Maik >
...Digikam then magically decides that my Digikam root album is no longer ~, but instead is /var/lib/foobar/cdoe (which does not exist).
Maybe it would be helpful if the original poster, alphsteiner, could check to see if he sees the same behavior: that Digikam changes the location of the Digikam root album. I don't think he mentioned it. It can be found under the Settings menu: Settings --> Configure digiKam. Then select "Collections" in the left-hand selection pane. Digikam changes mine from /home/cdoe to /var/lib/foobar/cdoe. Alphsteiner: What directory is shown for your 'Local Collections', and what SHOULD BE your directory shown for your 'Local Collections'??
BTW, I'm using a different version of Digikam than the OP. I'm using 3.5.0, which is the version in the Ubuntu Trusty repo. But I'm using a more recent version of sqlite3 (3.8.6), because of a problem with Digikam and the Ubuntu Trusty version of sqlite3 (3.8.2 ??).
> What directory is shown for your 'Local Collections', and what SHOULD BE your directory shown for your 'Local Collections'?? Let me backup the database first before I try.... It is the same as you: the 'Local collection' became the mountpoint of the bind mount. It is back the the correct directory when rewoving the bind mount.
I have tried to simplify the problem: - the normal photo directory is ~/Photos - run the commands: mkdir ~/A ~/Z mount --bind /home/alphonse/A /home/alphonse/Z Then the local directory becomes '/home/alphonse/Z/alphonse/Photos'
So, it looks like: - digikam tries to resolve /dev/mapper/home+alphonse/Photos - mount shows that /dev/mapper/home has two mountpoints, /home & /home/alphonse/Z - digikam is pecking the wrong one. Is that correct?
Yes, I can reproduce the issue from Comment 8... Maik
(In reply to alphsteiner from comment #9) > - mount shows that /dev/mapper/home has two mountpoints, /home & /home/alphonse/Z > - digikam is pecking the wrong one. Yes, a device has after a bind mount now two mountpoints with the same UUID. DigiKam get from the Solid API only the wrong mountpoint. At the moment it looks to me like a bug in Solid from. Maik
Thanks Maik for your investigations. I forward this entry to Solid component. Gilles
I'm not sure what the Solid API is that you mention, but I just noticed that gnome-disk-utility 3.10.0 is also showing incorrect "Mounted at" for home directory when bind mount is active. Perhaps this information would be helpful upstream.
Can you reproduce this problem using digiKam 6.2.0 pre-release of Linux AppImage bundle available here : https://files.kde.org/digikam/ Thanks in advance Gilles Caulier
Hi, Can you check if this problem still exist with last weekly bundle build of digiKam 7.0.0 available here: https://files.kde.org/digikam/ Thanks in advance Gilles Caulier
digiKam 7.0.0 stable release is now published: https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/ We need a fresh feedback on this file using this version. Thanks in advance Gilles Caulier
Version 7.1 still has this problem. Looking into why a bunch of my albums recently disappeared, I discovered the path that digikam thinks the albums are at is using a "mount --bind" (which I recently started using) on the albums original device rather than the original device path. For example, the device UUID is mounted as /home, and there was an album at specificPath /x/Pictures, so digikam considered the path to the album as /home/x/Pictures. Now there is a "mount --bind /home/x/somepath /home/x/some/otherpath" active and digikam now thinks the path or the album is at /home/x/some/otherpath/x/Pictures Experimentally I configured a new Local Collection in digikam selecting folder /home/x/TestPictures which works fine. I find in the database that digikam has in this case used the UUID of my root partition and then the full path from root as the specificPath. So my work-around will be to update the AlbumRoots.identifier in the database to use my root partition UUID and then full base path for AlbumRoots.specificPath. (Poking around in the database, it seems at some point when digikam could not find the album paths it seems to have set all the Albums.albumRoot fields to 0, which is non-existant, and Images.album is set to null. Fortunately for me I have all my metadata written to the image files (I hope!), so I'm not too concerned. But having packed my AlbumsRoots as described, digikam does appear to be just rescanning all the files as if new. I see in the database now duplicate Images records for a filename, one with correct Albums.id and one with null. Scary stuff. This is a brutal situation, even if rare, if database metadata is lost, as it seems to be.)
Updating or changing the UUID and path is easily possible in current digiKam versions in the GUI from the collection settings. Maik
digiKam 7.2.0 official release is published with more than 360 files closed from bugzilla: https://www.digikam.org/news/2021-03-22-7.2.0_release_announcement/ Can you reproduce the dysfunction with this version ? Thanks in advance for your feedback Gilles Caulier
Hi all, digiKam 8.0.0 is out. Problem still reproducible ? Best regards Gilles Caulier
Git commit f48fc133ec0f0e5656d4d21fff52278e3d81a636 by Maik Qualmann. Committed on 09/09/2023 at 21:28. Pushed by mqualmann into branch 'master'. use a UUID file for the primary detection of the right collection - The UUID file is saved in the ".dtrash" folder as "digikam.uuid". - The "digikam.uuid" file can be deleted, the detection goes back to the previous mechanisms, it will be created again at startup. - This commit also fixes a problem when creating the DTrash folder/info directories. Related: bug 470556, bug 398831, bug 452299 FIXED-IN: 8.2.0 M +9 -1 NEWS M +1 -1 core/libs/database/collection/collectionmanager.cpp M +8 -8 core/libs/database/collection/collectionmanager_album.cpp M +117 -82 core/libs/database/collection/collectionmanager_location.cpp M +125 -3 core/libs/database/collection/collectionmanager_p.cpp M +7 -0 core/libs/database/collection/collectionmanager_p.h M +20 -9 core/libs/dtrash/dtrash.cpp https://invent.kde.org/graphics/digikam/-/commit/f48fc133ec0f0e5656d4d21fff52278e3d81a636
alphsteiner@gmail.com, What's about this file using current 8.2.0 AppImage Linux bundle ? It's reproducible ? https://files.kde.org/digikam/ Note: bundle is now based on Qt 5.15.11 and KDE framework 5.110. Thanks in advance Gilles Caulier