| Summary: | Full album re-scan required if root folder temporarily unavailable | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | james |
| Component: | Database-Scan | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | REPORTED --- | ||
| Severity: | minor | CC: | caulier.gilles, metzpinguin |
| Priority: | NOR | ||
| Version: | 7.3.0 | ||
| Target Milestone: | --- | ||
| Platform: | Appimage | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
|
Description
james
2022-04-05 14:00:54 UTC
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 |