Bug 345391

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