SUMMARY Not sure if a bug or a feature request. I like to keep my database synchronized with the metadata found inside the pictures and vice-versa. I share several library folder with other relatives, and each one is free to manage and edit their portion of the library however they want. Therefore, so some folders are read-only. When you reorganize or modify tags in pictures that are read-only, digikam does not show any warning messages, it just carries on, makes the changes in digikam's database, and leave the original pictures untouched. This leads to a mismatch between the database and the metadata stored in the pictures. Re-reading the metadata on those pictures restores the original state, confirming that picture files were not written. I think there should be a warning message when a picture could not be modified, and also digikam should not change the metadata for those pictures in the database. STEPS TO REPRODUCE 1. Edit picture in read-only album (e.g. add a tag or a face rectangle). 2. Observe how changes appear to have been successfully applied in digikam. 3. Re-scan the picture for metadata. OBSERVED RESULT Picture is restored back to the original information. Other users cannot see those changes in their library, leading to inconsistencies between users. EXPECTED RESULT A warning should appear saying that this album/picture is read only. That edit should not be reflected in digikam's metadata. SOFTWARE VERSIONS digikam-6.0.0-beta1-20181009T192839-x86-64.appimage in Ubuntu 16.04 64bit ADDITIONAL INFORMATION If a mix of read-only and read-write pictures are modified, the database should reflect both changes, only changing tags/faces/dates/etc. for the read-write elements, leaving the rest intact.
What did you expect ? That DK write metadata in image even if file are read only ? We will never do that, even if it's possible technically. So for me it's not a bug, but a normal behavior. Gilles Caulier
No no, if a library is read only, of course there's no way of changing that. I meant that at least showing a warning when a file could not be modified would be helpful. I understand digikam is not responsible for other people's changes in a picture library, but it currently works very well in doing so, except for minor issues like this. A more simple solution I propose would be to automatically re-scan the picture metadata after a file has been modified. Such option already seems to exist (Settings, Configure digikam, Metadata, "Rescan files when files are modified"). This way, only changes that have been really applied will show in digikam, maintaining database-metadata integrity. So basically a Warning message + Metadata re-scan after changes.
It is actually a duplicate of its Bug 391891. There are users who purposely set their images to read only to protect them from change. I do not think they want to see a warning dialog all the time, probably no notification either. Maik
Well, yep, it's based on this bug, but here I focus on the fact that the library can differ from the picture metadata because digikam (and users) thinks these changes have been applied when they have not. For instance, imagine one user correcting the date on one picture. He hits on apply, the change is reflected in digikam, so he considers the job is done. But internally, digikam found the file is read-only, didn't apply any changes, and shows mismatching information that won't be updated to other people (which might use digikam or other software to view those pictures). As I said, just re-scanning metadata when files have been modified should solve this issue. Plus the read-only warning (or greying-out the OK and Apply buttons, I don't know, but at least some feedback would be helpful).
No, it does not work. For example, I have all my tags and all changes only in the database and also changed date. Therefore, re-reading and cleaning up the database before re-reading is also optional. And re-reading the metadata after each write would push performance into the basement when writing lots of metadata. For this they have the maintenance tool to later write the missing metadata into the images. Maik
Of course, re-reading the metadata from the images after changes should only occur if the option is checked (I suppose now it only detects external changes, right?). I actually manually re-read pictures after changes since date changes are not reflected in windows until I do so (bug #391440). It's a small price for keeping metadata-database consistency. Also, when writing large amounts of pictures, digikam already shows a warning. (PS: I don't get what you mean by "push performance into the basement")
After 3 weeks of work, i finally completed the compilation of AppImage using Qt 5.11.3 + QWebkit 5.212. New 6.1.0 pre-release AppImage bundle can be found here (64 bits only for the moment) : https://files.kde.org/digikam/ Please check if this bugzilla entry still valid. Thanks in advance Gilles Caulier
digiKam 7.0.0 stable release is now published and now available as FlatPak: https://www.digikam.org/news/2020-07-19-7.0.0_release_announcement/ We need a fresh feedback on this file using this version. Thanks in advance Gilles Caulier
Behavior still present. Digikam is not aware if a file is read-only when writing metadata and just assumes it has been written correctly.
@MarcP, digiKam 8.0.0 is out. This entry still valid with this release ? Best regards Gilles Caulier
Marc, What's about this file using current 8.2.0 AppImage Linux bundle ? It's reproducible ? https://files.kde.org/digikam/ Note: bundle is now based on Qt 5.15.11 and KDE framework 5.110. 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
Hi, yes, I think this behavior has not changed.
If a collection is not online, we now have an error icon for the respective collection in the album view. We could also show this icon if the collection is online but not writable. For each album individually this would probably be bad for performance reasons with network collections. Maik