My root album folder is made available by way of a mount command. Normally, this works just fine - Digikam sees it as a normal directory (and indeed, it is a normal directory). Today, my storage system experienced a temporary failure which caused the underlying storage volume not to mount, leaving an empty directory at the mount point. I started Digikam, and it immediately noticed that the root directory was empty, and reported that I had zero photos. I resolved the underlying issue with the mount point, ran the mount command, and restarted Digikam. Digikam is now re-scanning all the files under this directory. This wouldn't be a problem, except for the fact that I have hundreds of thousands of photos, and so this process is going to take hours. I believe Digikam should be able to recognise an empty root folder as an error state (if it previously had contents), and warn the user before proceeding, in order to give the user the opportunity to resolve the issue. STEPS TO REPRODUCE 1. Start Digikam with one of the previously-non-empty root album folders being empty OBSERVED RESULT 1. Digikam starts the "Find new items" process. EXPECTED RESULT 1. Digikam recognizes that it was expecting to find files, and warns the user that they are not present, before doing anything else. SOFTWARE/OS VERSIONS Build date: 10/07/2021 17:12 (target: RelWithDebInfo) Rev.: 206597cbfed3946264f9babebd666538fb2ff326 (installed from AppImage)
In fact, this behavior is normal. If you have set the image folder as a local collection, the folder MUST be available. It is unlikely that a local drive you are booting from is unavailable. If you are not sure that the drive or mountpoint is not always available, you must set the collection as a network collection. Maik
Well, I was pretty sure this local directory was going to always be available, until it wasn't. Is there any downside to marking a location as a network collection?
There aren't really any downsides. The advantage is that if the mount point is empty, the collection is not deleted from the database. A collection as a removable drive should also work in your case. However, we are then dependent on the Solid Framework and in conjunction with your system that all drive events and statuses are sent to digiKam correctly. Maik
What if I ask the question the other way around:- is there any advantage to Digikam's behaviour of deleting a local collection from the database if/when the directory is unavailable? I would find it more user-friendly to put up a warning first, in case I had done something easily correctable like accidentally move the folder.
The question arises what happens if you mount a wrong drive in the mount path. Your database will then also be rebuilt. This can also be avoided when using a removable drive collection type as the drive UUiD is checked. Furthermore, the question arises as to how many deleted folders or files should a warning appear in order not to annoy users who make a lot of external changes. In any case, you should have a backup of the database that is not too old. Maik
Maik, I think the question from this file have received a response... no ? File can be closed ? Gilles
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 345391 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
James, What's about this file using current 8.2.0 AppImage Linux bundle ? It's reproducible ? https://files.kde.org/digikam/ Thanks in advance Gilles Caulier
Hi all, The digiKam 8.4.0 Appimage bundle pre-release is now based on last modern frameworks Qt 6.7.0 and KDE 6.2.0. File can be downloaded at usual place : https://files.kde.org/digikam/ Take a care : the bundle is named with the suffix "-Qt6" not "-Qt5". This bundle is compiled under Ubuntu 22.04 and require a Linux with GlibC version >= 2.35 to run. Can you reproduce the dysfonction with this version? Thanks in advance Gilles Caulier