Sidecar file management fails for images that are actually symlinks to write-protected files in write-protected folders. This used to work in digikam 4.x. Note that the sidecar file is correctly written next to the symlink if the folder containing the target of the symlink is writeable. This is strange, as nothing is supposed to be written to that folder anyway. Reproducible: Always Steps to Reproduce: - Configure metadata settings: -- Check "Read from sidecar files" -- Check "Write to sidecar files" -- Select "Write to XMP sidecar only" - Start with a raw image "test.CR2" in an empty folder. Then: $ chmod a-w test.CR2 $ mkdir subdir $ mv test.CR2 subdir/ $ chmod a-w subdir $ ln -s subdir/test.CR2 link_to_test.CR2 - Now open the folder containing the symlink in digikam. - Change metadata of the symlink (not the original file in the subfolder!), e.g. Rating or Tags. - Select "Album > Write Metadata to Images" Actual Results: Nothing, not even an error message. Expected Results: A new sidecar file "link_to_test.CR2.xmp" with the changed metadata is present Relevant console output: digikam.metaengine: "/path/to/test/link_to_test.CR2" ==> Title: QMap() digikam.metaengine: "/path/to/test/link_to_test.CR2" ==> Comment: QMap() digikam.metaengine: "/path/to/test/link_to_test.CR2" ==> Pick Label: 0 digikam.metaengine: "/path/to/test/link_to_test.CR2" ==> Color Label: 0 digikam.metaengine: "/path/to/test/link_to_test.CR2" ==> Rating: +++++++++++ 1 digikam.general: Writting tags digikam.general: -------------------------- New Keywords ("Foo Bar") digikam.metaengine: "/path/to/test/link_to_test.CR2" ==> Read Iptc Keywords: () digikam.metaengine: "/path/to/test/link_to_test.CR2" ==> New Iptc Keywords: ("Foo Bar") digikam.metaengine: xmlACDSee "<Categories><Category Assigned=\"0\">Country<Category Assigned=\"1\">Foo Bar</Category></Category></Categories>" digikam.metaengine: filePath "/path/to/test/link_to_test.CR2" is a symlink. Using target "/path/to/test/subdir/test.CR2" digikam.metaengine: Dir ' "/path/to/test/subdir" ' is read-only. Metadata not saved. digikam.general: One job is done digikam.general: List of Pending Jobs is empty digikam.general: Event is dispatched to desktop notifier through DBUS digikam.general: Cancel Main Thread digikam.general: Cancel Main Thread
I think the sidecar should be stored in the image folder. In this case, the "subdir" folder. And the "subdir" must be writable. I think the behavior of digikam4.x was wrong. Gilles, what do you think? Maik
The sidecar must be paced at the same dir than image. It's the logic current used (and always used in digiKam through Exiv2.) Note : currently, the full qualied name of image file is used, including the file extension. example : foo.nef will have foo.nef.xmp, which will be suitable with the same file name and other extension as jpeg (foo.jpg.xmp). There is an entry in bugzilla to be able to customized that, but it's not yet implemented. Gilles Caulier
Regarding the behaviour: Digikam does treat symlinks like "real files", e.g. every symlink has its own set of tags in the database. In my opinion it would make more sense to treat them as links internally too. So any operation on the link in the database is actually done on the original (operations on the image itself are anyway always on the original). On 24/07/16 20:44, Maik Qualmann via KDE Bugzilla wrote: > https://bugs.kde.org/show_bug.cgi?id=366036 > > Maik Qualmann <metzpinguin@gmail.com> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |metzpinguin@gmail.com > > --- Comment #1 from Maik Qualmann <metzpinguin@gmail.com> --- > I think the sidecar should be stored in the image folder. In this case, the > "subdir" folder. And the "subdir" must be writable. I think the behavior of > digikam4.x was wrong. Gilles, what do you think? > > Maik >
> Regarding the behaviour: Digikam does treat symlinks like "real files", > e.g. every symlink has its own set of tags in the database. This is the behavior I would consider correct. Being able to use symlinks that are treated as normal files is an essential part of my workflow (tm): I use git with git-annex to manage my photos. The raw files are added via git-annex (and therefore replaced by symlinks to read-only files in read-only directories), while the sidecar files remain normal files managed by pure git. The raw files are never supposed to be changed anymore, while the metadata is kept under version control independent of a single tool (I use darktable for raw processing and digikam for almost everything else)
Git commit 19446b5d9a7bb63164232dfe9db3135b629337b7 by Maik Qualmann. Committed on 24/07/2016 at 19:32. Pushed by mqualmann into branch 'master'. write sidecar file in the same folder as image also over symlink FIXED-IN: 5.1.0 M +4 -4 libs/dmetadata/metaengine.cpp M +1 -1 libs/dmetadata/metaengine_p.cpp http://commits.kde.org/digikam/19446b5d9a7bb63164232dfe9db3135b629337b7
I now see the Comment 4. But the behavior of digiKam4.x was a mistake. DigiKam requires the sidecar in the same folder as the original image. Maik
In digiKam4.x was the writing from metadata about symlinks incorrectly. The real image path was not resolved correctly. Therefore, the change in digiKam5. Maik
Also Darktable created not a sidecar file and prints a exiv2 exception. Maik
Maik: So what is the behaviour after your commit: Does digikam handle symlinked images like unique images (so unique database entry, e.g. tags) or just as pointers to the real image (so all symlinks pointing to the same file have the same database information)? Thanks for clarification. On 24/07/16 22:05, Maik Qualmann via KDE Bugzilla wrote: > https://bugs.kde.org/show_bug.cgi?id=366036 > > --- Comment #8 from Maik Qualmann <metzpinguin@gmail.com> --- > Also Darktable created not a sidecar file and prints a exiv2 exception. > > Maik >
Just FYI: At least on my machine (up-to-date ArchLinux), the darktable versions 1.6.7 up to 2.0.5 handle the scenario described above as expected (respect symlinks, create/update sidecar file next to symlink). (In reply to Maik Qualmann from comment #8) > Also Darktable created not a sidecar file and prints a exiv2 exception. > > Maik
So I just opened digikam for the first time after compiling it with Maik's commit. It looks like digikam now detects the symlinks as duplicates. This output was printed repeatedly while scanning for new items: digikam.database: Recognized "*somefile*" as identical to item 56019 For testing I looked up which file has ID 56019 and changed a tag on it. This change is then not visible in *somefile*. The same is true the other way round. So digikam seems to recognize that these are the same items but it does not do anything about it. On 25/07/16 20:18, Thomas Reifenberger via KDE Bugzilla wrote: > https://bugs.kde.org/show_bug.cgi?id=366036 > > --- Comment #10 from Thomas Reifenberger <tspam+bugs.kde.org@rfnbrgr.de> --- > Just FYI: At least on my machine (up-to-date ArchLinux), the darktable versions > 1.6.7 up to 2.0.5 handle the scenario described above as expected (respect > symlinks, create/update sidecar file next to symlink). > > (In reply to Maik Qualmann from comment #8) >> Also Darktable created not a sidecar file and prints a exiv2 exception. >> >> Maik
You must to force digiKam to rescan metadata to resync database contents. Try buttons on the bottom of Captions/Tags sidebar tab. Other way is to use Maintenance tool. Gilles Caulier
The only "rescan metadata" option I find is "read metadata from file", but I do not currently write any metadata to file with digiKam, I store tags only internally. So the behavior is that digiKam reads and writes metadata from/to just one file (the original) but keeps separate database entries? If this is the case, that would be very inconsistent. Either Thomas' approach: Keep separate metadata for every file, thus using sidecar file along symlink or Only read/write to the original and one database entry for a file and all symlinks pointing to it need to be used. On 26/07/16 07:50, via KDE Bugzilla wrote: > https://bugs.kde.org/show_bug.cgi?id=366036 > > --- Comment #12 from caulier.gilles@gmail.com --- > You must to force digiKam to rescan metadata to resync database contents. > > Try buttons on the bottom of Captions/Tags sidebar tab. > > Other way is to use Maintenance tool. > > Gilles Caulier >