Version: 0.10.0 (using KDE 4.2.2) OS: Linux Installed from: Ubuntu Packages Sometimes I do use symlinks in my workflow. For example I copy images from archive folders to export folders as symlinks (I use Krusader for that). The digikam will display symlink, this is ok. Though it will not indicate that this not not the original image but symlink. I think this should be indicated. Another problem is that when I edit matadata of the symlinked image, the symlink actually converts into the original file and original file on archive location turns invalid (0 byte). I think ability of creating symlinks is very beneficial for any DAM software. It enables to sort same data in more then one physical structure. Copying symlinks to export folder is typical example.
Equivalent and more general feature already avaialble via KDE 4.4.5 drag and drop to dolpin: 1) Select pictures in digikam 2) Drag and drop into dolphin file manager window while holding Ctrl+Shift Leaving bug status change to original reporter or assignee.
I'm not sure if I understand. You suggest to use hardlinks instead of symlinks, is it? I actually avoid using of hardlinks in my archive. The problem here is especially with backing-up. On original file system where you created hardlink, it's ok - it's two files entries and one data. Thought once you copy or rsync your archive to backup storage - it will create two separate files and twice more data. And that you definitely don't want. Hardlinks are great thing for example in creating incremental/differential backups, though for the purpose of archive structuring I believe symlink is better suited.
Drag and drop into dolphin file manager window while holding Ctrl+Shift creates symbolic links. This could be an external solution to your digikam feature request. It seems we both know and use the differences between copying, symbolic and hard links.
Ok, I understand. Actually as I indicated in the original report I can create symlinks using Digikam and Krusader (file manager of my choice). The serious problem is in the paragraph no 2 and 3 of original post - it's inability of digikam to recognize, indicate and handle symlinks correctly. I believe this is still problem with current version so this issue is still valid.
(In reply to comment #2) > I actually avoid using of hardlinks in my archive. The problem here is > especially with backing-up. On original file system where you created hardlink, > it's ok - it's two files entries and one data. Thought once you copy or rsync > your archive to backup storage - it will create two separate files and twice > more data. And that you definitely don't want. rsync and many other backup utilities can handle hardlinks properly. You just have to pass it the -H or --hard-links switch to tell it to look for and preserve hardlinks on both sides.
*** Bug 310153 has been marked as a duplicate of this bug. ***
I think, this bug report contains two different symlink "feature requests"/"bugs": 1. The original report describes the problem, that a user can't see, if an image is related to a "real" file or just a symbolic link. (I agree, it would be very nice to see the difference and, optionally, to hide each one of those kinds - means: Sometimes I like to see the real ones, only, sometimes the symlinks, and in some cases I need both) 2. The first comment by Johannes Nieß describes a feature which was IMHO available in earlier versions of digiKam isn't available anymore in 2.8.0 which I'm using in Ubuntu 12.10 right now. The availability to easily create symlinks to a list of selected images by ctrl-shift-drag to an external folder (or even an internal album) is extremely useful: It connects the "outside world" to the digiKam DB without just copying the images files to another location. I used it to create a selection for ordering prints or to burn those images on a CD. With a folder of symlinked images I can use any tool I like to do what I want, not just KIPI-plugins, and a symlink need just a few bytes in the FS instead of the MBs of an image file. (Even Windows NTFS, BTW, supports soft links, too, so the feature might also be interesting for Windows-Users) Since these are two different features, I would request to split this report into two.
Sorry, typo: I wanted to "suggest" the split.
*** Bug 338724 has been marked as a duplicate of this bug. ***
*** Bug 339064 has been marked as a duplicate of this bug. ***
*** Bug 326568 has been marked as a duplicate of this bug. ***
Thank you for the bug report. As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists. If this bug is no longer persisting or relevant please change the status to resolved.
Issue still persist since you can't recognize if displayed file is symlink or the actual picture.
*** Bug 485873 has been marked as a duplicate of this bug. ***