Bug 140175 - mishandling of symbolic links [patch]
Summary: mishandling of symbolic links [patch]
Status: RESOLVED FIXED
Alias: None
Product: digikam
Classification: Unclassified
Component: ImageEditor-Save (show other bugs)
Version: 0.9.1
Platform: Gentoo Packages Linux
: NOR normal with 20 votes (vote)
Target Milestone: ---
Assignee: Digikam Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-01-16 23:43 UTC by Pedro Venda
Modified: 2022-02-03 03:35 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 4.0.0


Attachments
Let the imag editor follow symlinks (1.43 KB, patch)
2010-03-21 18:01 UTC, Johannes Wienke
Details
also don't remove symlinks when writing metadata (2.37 KB, patch)
2010-03-21 18:30 UTC, Johannes Wienke
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Pedro Venda 2007-01-16 23:43:26 UTC
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.
Comment 1 Florian 2008-01-06 23:06:03 UTC
I can confirm this strange behavior for 0.9.3 (KDE 3.5.7 "release 72.4" openSUSE 10.3).
Comment 2 Arnd Baecker 2008-01-07 07:56:43 UTC
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?
Comment 3 Stuart Prescott 2008-12-08 01:26:35 UTC
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.
Comment 4 Sebastian 2008-12-09 16:11:36 UTC
I confirm this behaviour of symbolic links as well as hard links with digiKam 0.9.4 in Ubuntu 8.10.
Comment 5 Jonas Norlander 2008-12-15 13:18:24 UTC
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.
Comment 6 Johannes Wienke 2010-03-21 18:01:42 UTC
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.
Comment 7 Johannes Wienke 2010-03-21 18:30:25 UTC
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.
Comment 8 Johannes Wienke 2010-03-30 22:15:25 UTC
Could someone please review these patches before they cannot be applied to trunk anymore ;)
Comment 9 Andi Clemens 2010-10-01 23:30:05 UTC
The patch still applies to trunk :-)

Gilles,

can you test this on Windows?

Andi
Comment 10 caulier.gilles 2010-10-02 15:18:33 UTC
i will check it

Gilles
Comment 11 Andi Clemens 2010-11-13 12:44:19 UTC
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?
Comment 12 Andi Clemens 2010-11-13 13:15:52 UTC
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
Comment 13 Andi Clemens 2010-11-13 13:16:44 UTC
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
Comment 14 Andi Clemens 2010-11-13 13:17:57 UTC
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?
Comment 15 caulier.gilles 2010-12-05 11:30:14 UTC
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
Comment 16 caulier.gilles 2010-12-05 11:35:28 UTC
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
Comment 17 Andi Clemens 2011-03-09 08:15:05 UTC
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.
Comment 18 Leif Huhn 2011-07-09 14:39:13 UTC
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).
Comment 19 Marcel Wiesweg 2012-03-19 20:34:44 UTC
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?
Comment 20 caulier.gilles 2013-11-25 12:47:03 UTC
Following comment #17 from Andi, i close this file now...

Gilles Caulier