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: [hidden email] Reporter: [hidden email] 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 -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
https://bugs.kde.org/show_bug.cgi?id=366036
Maik Qualmann <[hidden email]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[hidden email] --- Comment #1 from Maik Qualmann <[hidden email]> --- 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 -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=366036
[hidden email] changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[hidden email] --- Comment #2 from [hidden email] --- 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 -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by bugzilla_noreply
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). On 24/07/16 20:44, Maik Qualmann via KDE Bugzilla wrote: > https://bugs.kde.org/show_bug.cgi?id=366036 > > Maik Qualmann <[hidden email]> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |[hidden email] > > --- Comment #1 from Maik Qualmann <[hidden email]> --- > 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 > _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=366036
--- Comment #3 from Simon <[hidden email]> --- 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). On 24/07/16 20:44, Maik Qualmann via KDE Bugzilla wrote: > https://bugs.kde.org/show_bug.cgi?id=366036 > > Maik Qualmann <[hidden email]> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |[hidden email] > > --- Comment #1 from Maik Qualmann <[hidden email]> --- > 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 > -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=366036
--- Comment #4 from Thomas Reifenberger <[hidden email]> --- > 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) -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=366036
Maik Qualmann <[hidden email]> 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 <[hidden email]> --- 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 -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=366036
--- Comment #6 from Maik Qualmann <[hidden email]> --- 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 -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=366036
--- Comment #7 from Maik Qualmann <[hidden email]> --- 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 -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=366036
--- Comment #8 from Maik Qualmann <[hidden email]> --- Also Darktable created not a sidecar file and prints a exiv2 exception. Maik -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
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. On 24/07/16 22:05, Maik Qualmann via KDE Bugzilla wrote: > https://bugs.kde.org/show_bug.cgi?id=366036 > > --- Comment #8 from Maik Qualmann <[hidden email]> --- > Also Darktable created not a sidecar file and prints a exiv2 exception. > > Maik > _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=366036
--- Comment #9 from Simon <[hidden email]> --- 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. On 24/07/16 22:05, Maik Qualmann via KDE Bugzilla wrote: > https://bugs.kde.org/show_bug.cgi?id=366036 > > --- Comment #8 from Maik Qualmann <[hidden email]> --- > Also Darktable created not a sidecar file and prints a exiv2 exception. > > Maik > -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=366036
--- Comment #10 from Thomas Reifenberger <[hidden email]> --- 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) > Also Darktable created not a sidecar file and prints a exiv2 exception. > > Maik -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
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. On 25/07/16 20:18, Thomas Reifenberger via KDE Bugzilla wrote: > https://bugs.kde.org/show_bug.cgi?id=366036 > > --- Comment #10 from Thomas Reifenberger <[hidden email]> --- > 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) >> Also Darktable created not a sidecar file and prints a exiv2 exception. >> >> Maik _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=366036
--- Comment #11 from Simon <[hidden email]> --- 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. On 25/07/16 20:18, Thomas Reifenberger via KDE Bugzilla wrote: > https://bugs.kde.org/show_bug.cgi?id=366036 > > --- Comment #10 from Thomas Reifenberger <[hidden email]> --- > 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) >> Also Darktable created not a sidecar file and prints a exiv2 exception. >> >> Maik -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=366036
--- Comment #12 from [hidden email] --- 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 -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
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. On 26/07/16 07:50, via KDE Bugzilla wrote: > https://bugs.kde.org/show_bug.cgi?id=366036 > > --- Comment #12 from [hidden email] --- > 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 > _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
In reply to this post by bugzilla_noreply
https://bugs.kde.org/show_bug.cgi?id=366036
--- Comment #13 from Simon <[hidden email]> --- 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. On 26/07/16 07:50, via KDE Bugzilla wrote: > https://bugs.kde.org/show_bug.cgi?id=366036 > > --- Comment #12 from [hidden email] --- > 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 > -- You are receiving this mail because: You are the assignee for the bug. _______________________________________________ Digikam-devel mailing list [hidden email] https://mail.kde.org/mailman/listinfo/digikam-devel |
Free forum by Nabble | Edit this page |