| Summary: | Collection Storage Location Unavailable Mac | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Geoff King <gsking1> |
| Component: | Database-Media | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | caulier.gilles, metzpinguin |
| Priority: | NOR | ||
| Version: | 8.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | macOS (DMG) | ||
| OS: | macOS | ||
| Latest Commit: | https://invent.kde.org/graphics/digikam/-/commit/f48fc133ec0f0e5656d4d21fff52278e3d81a636 | Version Fixed In: | 8.2.0 |
| Sentry Crash Report: | |||
|
Description
Geoff King
2023-06-02 12:38:46 UTC
If the removable media collection are only recognized again when the collection refresh is performed, it would mean that the partition UUID is changing on macOS for whatever reason. Maik Happened again - Something is changing during Mac updates. Last night updated from Mac 13.4.19(c) to Mac 13.5 and it happened again. The file path was lost. Had to reassign the two folders designated as "Collections on Removable Media". If macOS now changes the partition UUID during an update, possibly links it to the version number and our Solid API used does not make any errors, then we will not be able to do anything here. My idea has been for a long time that we write a file in the collection root path with a UUID created by digiKam. This would allow us to uniquely identify a collection regardless of type, which would solve some problems. On the other hand, some users may not want digiKam to create such a file in the collection. Gilles what do you think? Maik it's a good idea. I recommend to hide this UUID settings file in the dtrash directory. This one is always attached to the collection. All at the same place is always good. 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 398831, bug 452299, 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 Hello, I had this happen again. Mac updated to 13.6 yesterday. Digikam 8.2 Build Date 9/16/23 12:40 PM As before, had to update the path of the two collections for Collections on Removable Media. The Local Collection folder was unaffected. And the two collections on the removable media were already mounted with the current digiKam version before? Maik (In reply to Maik Qualmann from comment #7) > And the two collections on the removable media were already mounted with the > current digiKam version before? > > Maik Yes. I had used them a few days before. I don’t think I defined ( or created ) those settings on 8.2, not sure if that matters. Now check whether the digikam.uuid file exists in the removable media in the root directory of the collection in the .dtrash folder. We then have to wait until the next macOS update. Maik (In reply to Maik Qualmann from comment #9) > Now check whether the digikam.uuid file exists in the removable media in the > root directory of the collection in the .dtrash folder. We then have to wait > until the next macOS update. yes - each collection contains a digikam.uuid |