Version: 0.9.1-svn (using KDE KDE 3.5.5) Installed from: Gentoo Packages Compiler: gcc (GCC) 4.1.1 (Gentoo 4.1.1-r3) CFLAGS="-march=pentium-m -mtune=pentium-m -mmmx -msse -msse2 -mfpmath=sse,387 -fomit-frame-pointer -funroll-loops -O2 -pipe" OS: Linux I'm creating sub-albums of my main albums where I symlink the files corresponding to my selected pictures to geotag and comment and later to publish on the web. So far it works well: digikam displays the pictures (symlinks) correctly in the sub-album and if I change the picture in the main album, it shows up changed in the sub album. The issue is doing it the other way around: changing pictures in the sub album (changing/adding tags) does a strange thing. The symlink is replaced by the changed file and the source file is replaced by another with the same name and with size 0. Like this: before: pjlv@archon ... $ ls -l 20061231T180626.JPG ../20061231T180626.JPG ... 3569645 Jan 2 01:34 ../20061231T180626.JPG ... 22 Jan 16 12:50 20061231T180626.JPG -> ../20061231T180626.JPG after: pjlv@archon ... $ ls -l 20061231T180626.JPG ../20061231T180626.JPG ... 0 Jan 16 13:13 ../20061231T180626.JPG ... 3569742 Jan 16 13:13 20061231T180626.JPG I understand that this technique may seem a dirty hack to "fool" digikam, but nevertheless, it should handle symlinks like symlinks. How to reproduce: 0. select an album [~/album] 1. create a sub-album (on digikam or on the shell) [~/album/subalbum] 2. symlink an image from the album into sub-album (on the shell) [~/album/subalbum/img001.jpg -> ~/album/subalbum/img001.jpg] 3. navigate into the sub-album folder and change the comment of the linked image file 4. watch the resulting files [~/album/subalbum/img001.jpg (should have 0 bytes), ~/album/subalbum/img001.jpg (shoud no longer be a symlink and is the altered image file)] Expected behaviour: 4. the symlink in ~/album/subalbum/img001.jpg remains a symlink to ~/album/img001.jpg and ~/album/img001.jpg is changed to reflect the new comment tag.
I can confirm this strange behavior for 0.9.3 (KDE 3.5.7 "release 72.4" openSUSE 10.3).
It *might* be that internally the modification is done on a temporary file which is then copied over to the original one (which, in this case, would not be the file to which the symlink goes, but the symlink itself). Using symlinked directories should work ok though. Have you tried using tags to mark the selected pictures for geotagging, commenting publishing?
I see this behaviour with digikam 0.9.4 in Debian Lenny (from Debian digikam package 2:0.9.4-1). Quite annoying, really, to have the symlink farm wiped out and the original files truncated to 0 bytes too. Probably an associated problem is that digikam doesn't play nicely with hardlinks either.
I confirm this behaviour of symbolic links as well as hard links with digiKam 0.9.4 in Ubuntu 8.10.
I can confirm this bug to on Kubuntu 8.10 with digikam 0.9.4 (0.9.4-1ubuntu1). I think that with the comments on this bug the status and specially severity should change as this can make you loose pictures. I spent several hours comparing and restoring pictures from a backup two different times before I realized that it was a bug related to some of my pictures was symlinked.
Created attachment 41806 [details] Let the imag editor follow symlinks This patch lets the image editor follow symlinks for saving images. Could someone please test this, especially on windows because the file name for preserving the windows file permissions now points to the symlink target and I don't know how windows reacts on this.
Created attachment 41807 [details] also don't remove symlinks when writing metadata This patch also includes checking symlinks when writing metadata. Nevertheless, the database will not be notified for changes on the source of the symlink. I don't know if there is a good solution to model this.
Could someone please review these patches before they cannot be applied to trunk anymore ;)
The patch still applies to trunk :-) Gilles, can you test this on Windows? Andi
i will check it Gilles
Gilles, I can not test this under Windows or Mac OSX, I will checkout the patch, modify it (if needed) and send the patch to you, so you can try it on these operating systems?
SVN commit 1196422 by aclemens: Check for correct symlink handling. CCBUG: 140175 M +17 -7 kexiv2.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1196422
SVN commit 1196423 by aclemens: Check for correct symlink handling. CCBUG: 140175 M +14 -2 editorwindow.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=1196423
Gilles, I added the patch to libkexiv2 and to digiKam, maybe you can test the other operating sytems now and close the bug if succeeded?
Under MacOS X, it's sound fine. Symbolic links as like under Linux. Under windows, Symbolic links do not exist. It's replaced by the windows shortcuts concept ? Gilles Caulier
Under windows windows shortcuts concept is not supported as well by digiKam kioslave. I suspect a problem in KUrl. Typically, if i install digiKam through NSIS installer on a fresh XP computer, digiKam use by default USERS/My Images as root collection. In this folder, there is a shortcuts on common samples images provided by windows. The link to this folder is visible under digiKam, but items are not displayable as thumbs/preview/edit... All operation fail as well, as metadata patch. Gilles Caulier
As far as I know, Windows doesn't have symbolic links, so the described error is ok in this case? I guess we can close this bug if the patch works fine under Mac and Linux.
SVN commit 1196422 from comment #12 is responsible for bug 275311. I really like that digikam makes an attempt to follow symlinks when editing pictures. However, this is interacting badly with the xmp sidecar code, because digikam is trying to put the sidecar next to the real file (when I think it makes more sense to put it near the symlink). Ideally, I'd like it if digikam tried to put the sidecar next to the symlink, but then checked if the sidecar was already a symlink and follow that before editing it. Also, commit 1196422 has a surprising property. It doesn't walk symlinks all the way down. It only dereferences one. It should probably resolve them farther (but not too far...avoid getting stuck in a loop).
Symlink handling for sidecars has recently been improved, see bug 275311. Please check with current git or coming 2.6 if any issues still exist, I would like to make sidecars work for 2.6. Is any other issue pending for the original, very old, bug report or can we close?
Following comment #17 from Andi, i close this file now... Gilles Caulier