Created attachment 124942 [details] Patch that fixes the issue My images are stored as a symlink to a readonly file (and directory) in git annex. I would like digikam to write sidecar files in the same directory (which is read/write) as the symlink (Not in the git annex). This is not possible because the save logic first checks if the image is stored in a directory with read write permissions. STEPS TO REPRODUCE 1. Load image that is a symlink to a file stored in a readonly directory. Like this ls -l 20140104_2717.jpg -> ../../.git/annex/objects/Xx/ZV/BLAKE2B256-s7492892--75f3a3f49dac4cd69004c8a6ca4278d3a88b7a6054466c4a8fc26cd0b5a9d312/BLAKE2B256-s7492892--75f3a3f49dac4cd69004c8a6ca4278d3a88b7a6054466c4a8fc26cd0b5a9d312 2. Configure digikam to read/write to sidecar files 3. Tell digikam to write metadata for file. Item->Write Metadata to file OBSERVED RESULT Side car file fails to write. digikam.metaengine: "/home/david/src/media/2014/2014-01-04/20140104_2717.jpg" ==> New Iptc Keywords: ("XYZ") digikam.metaengine: filePath "/home/david/src/media/2014/2014-01-04/20140104_2717.jpg" is a symlink. Using target "/home/david/src/media/.git/annex/objects/Xx/ZV/BLAKE2B256-s7492892--75f3a3f49dac4cd69004c8a6ca4278d3a88b7a6054466c4a8fc26cd0b5a9d312/BLAKE2B256-s7492892--75f3a3f49dac4cd69004c8a6ca4278d3a88b7a6054466c4a8fc26cd0b5a9d312" digikam.metaengine: Dir "/home/david/src/media/.git/annex/objects/Xx/ZV/BLAKE2B256-s7492892--75f3a3f49dac4cd69004c8a6ca4278d3a88b7a6054466c4a8fc26cd0b5a9d312" is read-only. Metadata not saved. EXPECTED RESULT Side car file is written into directory where original symlink is. SOFTWARE/OS VERSIONS Linux/KDE Plasma: Ubuntu 19.10 ADDITIONAL INFORMATION Looking at the code the logic is flawed. Please see attached patch which fixes the issue for me. Thanks
I haven't tested the patch yet. But if I see it correctly, you are now using the original image path for the sidecar. For previous users who used images via symbolic links, this would mean that the sidecar is no longer saved next to the original image. Maik
Hi Maik, Yes this change would change existing behaviour. If you think there are others that are using that model I'm happy to have a try at making the behaviour configurable to support my git annex model and the original model. I don't think it should be too difficult to support. Regards David
Hi Maik, A few further comments. 1) The comment at the top of the save function matches what I was expecting. // If our image is really a symlink, we should follow the symlink so that // when we delete the file and rewrite it, we are honoring the symlink // (rather than just deleting it and putting a file there). // However, this may be surprising to the user when they are writing sidecar // files. They might expect them to show up where the symlink is. So, we // shouldn't follow the link when figuring out what the filename for the // sidecar should be. 2) Looking at the load function. I can't see how it would load a sidecar file that was stored where the original file is rather than in the directory with the symlink. ie mydir <- Directory I load in digikam |- myfile.jpg -> ../someotherdir/myotherfilename.jpg someotherdir |- myotherfilename.jpg |- myotherfilename.jpg.xmp <-- This won't be found if I understand the code correctly as it doesn't follow the symlink to the original file first.
Hello all, I've hit the exact same issue as David, as I am now also using git-annex. Could I please ask that his patch be applied (or a similar solution found). Using git annex to manage photo libraries is fantastic, and having to `git annex unlock` a whole directory before editing metadata is very frustrating. A "git annex mode" check box in settings could be used to selectively enable this behaviour if you are concerned with backwards compatibility. I'll have a brief attempt at implementing this in the next hour or so, and if successful I'll make a PR on gitlab/invent. To recap: git annex stores raw files as symlinks to an immutable directory (good, my RAWs won't change), with *.xmp stored as normal files (tracked by ye olde git). Digikam *should* be able to write to e.g. library/IMG0002.CR2.xmp, but refuses to as library/IMG0002.CR2 is an immutable symlink. Digikam correctly *reads* metadata in this case, and will write to it if one does `git annex unlock library/IMG0002.CR2` (which replaces the symlink with a copy of the immutable content, i.e. makes the situation "normal"). Best, kevin
Created attachment 144688 [details] Updated patch Hi Kevin, Please see my attached patch that has been tweaked a little for the latest master. Every time I update master I've just been rebasing my patch. A little frustrating but it has allowed me to continue to use git annex. Regards David
Created attachment 144702 [details] Updated patch I quickly created a new patch, this should restore the old behavior. If the regular path is writable, the sidecar goes there, if not, to the symlink. Please test. Maik
Git commit 32ea05d81842a311dd11c6d983e895fc19d1da48 by Maik Qualmann. Committed on 22/12/2021 at 07:18. Pushed by mqualmann into branch 'master'. write sidecar to the symlink if destination dir write protect FIXED-IN: 7.5.0 M +1 -1 NEWS M +23 -14 core/libs/metadataengine/engine/metaengine_fileio.cpp https://invent.kde.org/graphics/digikam/commit/32ea05d81842a311dd11c6d983e895fc19d1da48
Hi Maik, Just tried your patch in master (32ea05d) and it seems to work fine for me. Thanks David