| Summary: | XMP sidecars are not written for symbolic links [patch] | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | ethan |
| Component: | Metadata-Sidecar | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | caulier.gilles, lb.kdebugzilla |
| Priority: | NOR | ||
| Version: | 2.0.0 | ||
| Target Milestone: | --- | ||
| Platform: | Ubuntu | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 2.0.0 | |
| Sentry Crash Report: | |||
| Attachments: |
Don't follow the symlink if we are writing to only the sidecar
Only follow the symlink when writing to the image file |
||
|
Description
ethan
2011-06-09 23:58:57 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. 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 |