When applying a tag to a selection of pictures in digikam, it is possible that some files are read only, and therefore the metadata won't be written to them. I noticed that when launching digikam from a shell. I think Digikam should warn the user that the file could not be modified, so you can act accordingly (give permissions, etc.).
Which file system do you use exactly ? Gilles Caulier
My pictures are stored in ext4 hard drive in a debian (jessie) server, shared through a samba (4.2.14) network share, and mounted as a network drive in Windows 10.
Under Windows, if you go with a console (cmd) in the directory an use "dir" to list all contents + properties, what do seen ? Gilles Caulier
Not much, just columns for the date, the hour, the file size, the file name, and the total size of the folder at the bottom. Here's an example: https://pastebin.com/dpdaM9dW
There is certainly an option to pass to dir to show the details : https://jpsoft.com/help/dir.htm Gilles Caulier
I think way to see permissions in windows is using the command icacls. Anyway, I corrected the permissions in the debian server as soon as I saw the read-only error in digikam's console, so I cannot show you exactly how it's seen from windows. But at least it seems that digikam is aware that the file could not be written, so I guess a warning could be shown in the user interface.
Just a heads up. This is an issue in linux too. If you write some metadata to a read-only file, digikam does not warn you, makes the changes to the database, but not to the file. If you re-read the metadata from digikam, those changes will revert. In the console, I can see the following error: Digikam::MetaEngine::Private::printExiv2ExceptionError: Cannot save metadata using Exiv2 (Error # 10 : /media/sshfs/retropie/media/usb2/Fotos/Fotos/2019-04-22 Aplec/P1230088.JPG: Failed to open file (w+b): Permission denied (errno = 13) But in the main interface, the problem goes unnoticed. I think this is currently the only situation where the metadata between the database and the pictures can be out of sync. In my opinion, just showing a warning (e.g. "Changes could not be saved.") at the progress bar at the bottom would be helpful for detecting these situations.
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
This problem is still present.
*** This bug has been marked as a duplicate of bug 220204 ***