| Summary: | mishandling of symbolic links [patch] | ||
|---|---|---|---|
| Product: | [Applications] digikam | Reporter: | Pedro Venda <pjvenda> |
| Component: | ImageEditor-Save | Assignee: | Digikam Developers <digikam-bugs-null> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | bacchus, bugs.kde.org, caulier.gilles, jonorland, lb.kdebugzilla |
| Priority: | NOR | ||
| Version: | 0.9.1 | ||
| Target Milestone: | --- | ||
| Platform: | Gentoo Packages | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | 4.0.0 | |
| Sentry Crash Report: | |||
| Attachments: |
Let the imag editor follow symlinks
also don't remove symlinks when writing metadata |
||
|
Description
Pedro Venda
2007-01-16 23:43:26 UTC
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 |