Version: 2.0.0 (using KDE 4.6.2) OS: Linux Because I am experimenting with using git-annex to store my photos, images in my library are not regular files, but instead are symbolic links. When I try to modify metadata for these images, digikam silently does not write XMP sidecar files, even though I have set "Write to XMP sidecar only". The same image, when copied to a new filename, does get an XMP sidecar written. Reproducible: Always Steps to Reproduce: $ cp ~/image1.jpg ~/Pictures $ ln -s ~/image2.jpg ~/Pictures In Digikam, add a tag to bath image1 and image2. Actual Results: ~/Pictures/image1.jpg.xmp is created, but ~/Pictures/image2.jpg.xmp is not. If ~/Pictures/image2.jpg.xmp existed already, it is unchanged. Expected Results: ~/Pictures/image1.jpg.xmp and ~/Pictures/image2.jpg.xmp are created containing the tag that was just added. I tried using kdebugdialog to turn on debugging output for digikam but I didn't get any messages about XMP files. On the other hand, I might have screwed up using kdebugdialog.
I'm having the exact same problem. I think what's happening here is that Digikam tries to write the .xmp file in the same directory as the real file. Git-annex has arranged the file permissions such that the real file exists in a directory without write permission. Digikam is probably silently failing when it tries to write the .xmp. This is a tricky one, because you could imagine another user using symbolic links in such a way that they would want the sidecar to be written in the same place as the real file (that is, the current behavior). For now I'm planning on compiling digikam myself and finding the code that notices symbolic links and changing it. I'll let you know what I find.
I think this code in extra/libkexiv2/libkexiv2/kexiv2.cpp may be responsible: // ensure that symlinks are used correctly QString fileName = filePath; QFileInfo info(fileName); if (info.isSymLink()) { kDebug() << "filePath" << filePath << "is a symlink." << "Using target" << info.symLinkTarget(); fileName = info.symLinkTarget(); } Unfortunately, the behavior we want is opposite of what the author of that code wanted.
Interestingly, Digikam only follows one level of symlink. It doesn't resolve the symlinks all the way down (if you have symlinks pointing to symlinks).
SVN commit 1196422 from bug 140175 comment #12 is responsible for this bug. As it turns out, they wanted to follow the symlink so that editing of symlinked files would work properly (not so the sidecar would appear near the real file). We could probably agree on a patch that causes the sidecar to appear near the symlink.
Created attachment 61730 [details] Don't follow the symlink if we are writing to only the sidecar Here's a patch that will avoid following the symlink if we are configured to write to only the sidecar. There is no point at all in following the symlink if we aren't editing the tag on the image (since the whole point of following the symlink is to edit the real file). With this patch, you can use digikam with sidecars and git annex.
Thanks. I will review your patch monday morning Gilles Caulier
Created attachment 61734 [details] Only follow the symlink when writing to the image file Please ignore the previous patch (also ignore the comments about pass by reference...I misread the original code). This patch should be a proper fix for the problem. Instead of traversing the symlink when we load the metadata, we only resolve it when we save. We only use the resolved path when writing out the file (not when computing the path for the sidecar). This resolves more than one level of symlink. It still does not handle the situation where the sidecar is a symlink.
Git commit 895fa43e61034daae00e70525d72482beeff1ca2 by Gilles Caulier. Committed on 11/07/2011 at 10:58. Pushed by cgilles into branch 'master'. apply patch #61734 and #61736 from Leif Huhn to manage XMP sidecar and symbolic links properlly - If sidecar exists, still read size, mimetype, comments, exif, and iptc from original image. - Only follow the symlink when writing to the image file. CCBUGS: 275311 CCBUGS: 272175 M +83 -49 libkexiv2/kexiv2.cpp http://commits.kde.org/libkexiv2/895fa43e61034daae00e70525d72482beeff1ca2