[digikam] [Bug 366036] New: Sidecar file is not written when image is symlink to write-protected directory

[Thomas Reifenberger via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=366036

Bug ID: 366036
Summary: Sidecar file is not written when image is symlink to
write-protected directory
Product: digikam
Version: 5.0.0
Platform: Archlinux Packages
OS: Linux
Status: UNCONFIRMED
Severity: normal
Priority: NOR
Component: Metadata-Sidecar
Assignee: digikam-***@kde.org
Reporter: tspam+***@rfnbrgr.de

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

[Maik Qualmann via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=366036

Maik Qualmann <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #1 from Maik Qualmann <***@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

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=366036

***@gmail.com changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |***@gmail.com

--- Comment #2 from ***@gmail.com ---
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

[Simon via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=366036

--- Comment #3 from Simon <***@gmail.com> ---
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).

Post by Thomas Reifenberger via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=366036
What |Removed |Added
----------------------------------------------------------------------------
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

[Thomas Reifenberger via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=366036

Post by Simon via KDE Bugzilla
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)

[Maik Qualmann via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=366036

Maik Qualmann <***@gmail.com> changed:

What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|UNCONFIRMED |RESOLVED
Version Fixed In| |5.1.0
Latest Commit| |http://commits.kde.org/digi
| |kam/19446b5d9a7bb63164232df
| |e9db3135b629337b7

--- Comment #5 from Maik Qualmann <***@gmail.com> ---
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

[Maik Qualmann via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=366036

--- Comment #6 from Maik Qualmann <***@gmail.com> ---
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

[Maik Qualmann via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=366036

--- Comment #7 from Maik Qualmann <***@gmail.com> ---
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

[Maik Qualmann via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=366036

--- Comment #8 from Maik Qualmann <***@gmail.com> ---
Also Darktable created not a sidecar file and prints a exiv2 exception.

Maik

[Simon via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=366036

--- Comment #9 from Simon <***@gmail.com> ---
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.

Post by Thomas Reifenberger via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=366036
Also Darktable created not a sidecar file and prints a exiv2 exception.
Maik

[Thomas Reifenberger via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=366036

--- Comment #10 from Thomas Reifenberger <tspam+***@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)

Post by Maik Qualmann via KDE Bugzilla
Also Darktable created not a sidecar file and prints a exiv2 exception.
Maik

[Simon via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=366036

--- Comment #11 from Simon <***@gmail.com> ---
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.

Post by Thomas Reifenberger via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=366036
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)

Post by Maik Qualmann via KDE Bugzilla
Also Darktable created not a sidecar file and prints a exiv2 exception.
Maik

[via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=366036

--- Comment #12 from ***@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

[Simon via KDE Bugzilla]

https://bugs.kde.org/show_bug.cgi?id=366036

--- Comment #13 from Simon <***@gmail.com> ---
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.

Post by Thomas Reifenberger via KDE Bugzilla
https://bugs.kde.org/show_bug.cgi?id=366036
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