SUMMARY This bug is related to bug #377849, which was been dealt with, but it only happens in one specific situation. I don't think it's Digikam's fault, but maybe something could be done to avoid losing a whole collection in the db. When a network share (containing the pictures) is connected through a sshfs mount, and the connection is lost at some point, the operating system sometimes is not aware of it. When you try to access that folder in a file browser, error messages similar to "sshfs - transport endpoint is not connected" are shown. Unmounting and mounting the network share usually solves the problem. Digikam (and any other software) also thinks that network share is still connected and accessible, so when it scans for new items, it sees that the path is still available (but it's not). However, it cannot access any of the pictures, so it decides to remove all the pictures in that collection, one by one. I found that the hard way the other day, when I found my database was empty due to that network error. This is likely a Linux-only problem, and the error should be corrected at the level of the OS (better detection of disconnected network folders), but maybe some mechanism could be implemented in Digikam to minimize situations like this. Like asking for a confirmation after several folders in a row couldn't be found, or just hiding but not deleting the files from the database, so they don't need to be rescanned the next time they are available. I don't know. STEPS TO REPRODUCE 1. Wait for a network interruption to "freeze" a sshfs mount point without unmounting it. 2. Tell digikam to scan for new folders/albums. OBSERVED RESULT Observe how the scan goes faster than usual, and at the end all albums have been removed from the database. EXPECTED RESULT Nothing should happen, as the picture library is not really available. Maybe mark those pictures as "not available". SOFTWARE/OS VERSIONS Ubuntu 18.04 and digikam-6.1.0-git-20190320T143140-x86-64.appimage ADDITIONAL INFORMATION I mount my network shares using the software called "autofs".
Git commit 123c4c28640dbcd52c7097d354e6e754a04c79d0 by Maik Qualmann. Committed on 24/03/2019 at 17:07. Pushed by mqualmann into branch 'master'. try to check if the trash is available M +5 -1 core/libs/database/collection/collectionmanager_location.cpp https://commits.kde.org/digikam/123c4c28640dbcd52c7097d354e6e754a04c79d0
New AppImage is available, can you please test if the problem still exists? Maik
I am trying to simulate the error. I'll report back when I've managed to replicate the conditions.
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. Best Regards Gilles Caulier
I can't say for sure it's been fixed, but I have not had that problem anymore. But maybe because my network is more stable, I don't know (my library is in a remote NAS, accessed through sshfs, and using a wifi network all along). You can close it and I would reopen it if it happened again.
Thanks for the feedback. I close this file now.