Bug 275311 - XMP sidecars are not written for symbolic links [patch]
Summary: XMP sidecars are not written for symbolic links [patch]
Alias: None
Product: digikam
Classification: Unclassified
Component: Metadata-Sidecar (show other bugs)
Version: 2.0.0
Platform: Ubuntu Packages Linux
: NOR normal (vote)
Target Milestone: ---
Assignee: Digikam Developers
Depends on:
Reported: 2011-06-09 23:58 UTC by ethan
Modified: 2017-08-11 14:11 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In: 2.0.0

Don't follow the symlink if we are writing to only the sidecar (1.60 KB, patch)
2011-07-09 18:22 UTC, Leif Huhn
Only follow the symlink when writing to the image file (4.54 KB, patch)
2011-07-09 20:56 UTC, Leif Huhn

Note You need to log in before you can comment on or make changes to this bug.
Description ethan 2011-06-09 23:58:57 UTC
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.
Comment 1 Leif Huhn 2011-07-09 05:24:07 UTC
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.
Comment 2 Leif Huhn 2011-07-09 05:42:58 UTC
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.
Comment 3 Leif Huhn 2011-07-09 06:47:52 UTC
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).
Comment 4 Leif Huhn 2011-07-09 14:41:48 UTC
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.
Comment 5 Leif Huhn 2011-07-09 18:22:25 UTC
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.
Comment 6 caulier.gilles 2011-07-09 18:35:19 UTC
Thanks. I will review your patch monday morning

Gilles Caulier
Comment 7 Leif Huhn 2011-07-09 20:56:35 UTC
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.
Comment 8 caulier.gilles 2011-07-11 09:03:16 UTC
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