Hello, On my Mac (Air M2. Ventura 13.2) I am loosing the collection settings occasionally. From Thumbnails double clicking the image shows: "The storage location of this image is currently not available". This has been going on for at least several months, and prior 7.x versions also I think. It will keep the collection settings for maybe a month or more. I'm guessing it may be due to updates being applied by Apple (maybe going from 13.3 to 13.4? and similar with prior versions) since it doesn't happen very often. When this happens, workaround is to go into Collection Settings and re-select the Collections. In this case today, the folder selected for "Local Collections" was okay. What wasn't connecting was the two folders I had listed under "Collections on Removable Media". These are two separate folders on the same external SSD drive. I keep this drive connected 98% of the time. Click the refresh button and re-assign those drives and all is good for another month or so. One thing I thought to try afterwards was to disconnect and re-connect that drive instead of rescanning - can try that next time it happens, but the drive seems to work fine in finder and other apps. STEPS TO REPRODUCE 1. No known steps, just happens periodically. Maybe every month or so. 2. OBSERVED RESULT "The storage location of this image is currently not available". EXPECTED RESULT Don't want images to lose the link to their locations on the disk. SOFTWARE/OS VERSIONS macOS: 13.4 KDE Plasma Version: KDE Frameworks Version: 5.104.0 Qt Version: 5.15.8
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