22

User case: inside the folder
~/Documents
you have a symlink to the folder
~/Images/Manual
when you click the symlink you are "teleported" to ~/Images/Manual, but the address bar on Dolphin shows
~/Documents/Manual
instead of the real path. This is counter intuitive and confusing because it shows a fake folder tree. In fact, clicking "up" will move you to ~/Documents if you arrived through the symlink, but will move you to ~/Images if you arrived on any other way. Really confusing.
There should be an option to make Dolphin show real paths.

I'm the original trigger of the idea (viewtopic.php?f=22&t=84150), and of course think that is a great idea, thanks RGB for submiting it

Your issue isn't in KDE, it's actually how the file system works.

lunarcloud wrote:Your issue isn't in KDE, it's actually how the file system works.

REpost of my previous comment with small correction

Do not agree. Dolphin should adapt it's behavior to what the user need. In such a case, with unix file-systems symlinks, program have the choice when working with them: or to resolve them or not. That's not the file system work to do that but the program which use this particular file-system feature to decide what to do. At least this should be configurable within Dolphin.

And this is not going against Dolphin philosophy of simplicity of use, there is nothing telling that resolving symlinks is less simple than not, I even thought that it is much more confusing not to resolve them.

Exactly. In the example I gave above it is clear that not resolving symlinks leads to confusing behaviour: arriving to the same folder by two different roads gives you two completely different responses to the same "up" action.

To me it seems like this is coming from a Windows point of view with Windows shortcuts. This is how symlinks work in Linux and I don't see a problem with it.

Many years passed since I last used windoze on a regular basis so, at least for me, this idea did not come from a windoze point of view. I want consistency: if I click "up" I want to go to the real up folder. To return to the folder were the symlink is I have the back button (or Alt+Left )

I like the current way. When I've created a symlink, I can often forget what it is and use it as a normal directory. Sure it felt strange at first (I was used to shortcuts in Windows), but now I like it.

For example, I have materials for my courses neatly organized in ~/documents. The structure makes it easy to find stuff, but it's a pain to quickly navigate to. Therefore I've created a symlink to the current course directory in my home directory.

Now I can treat the symlink as a normal directory without thinking about the structure in ~/documents. It's almost as if I've copied the directory to ~, but the content is the same all the time.

If you want a shortcut, you can create a .desktop file. This is not what symlinks are for, in my opinion.

afaik, Most tools on linux treat symlinks as if they were actual directories and the resolving of symlinks is left to the underlying file system. When you create a symlink, you are essentially creating a virtual copy of the other directory at the given location (virtual in that no copying occurs). This is the default/expected/'natural' behavior. I think it would be confusing to introduce inconsistency across tools as most people who are used to the default "linux way" of handling symlinks would be disturbed by the change in behavior.

Of course, most of those tools (at least most of the command-line tools for manipulating paths) allow for resolving symlinks (or acquiring the real path) or at least showing that symlinks were followed. Perhaps it could be useful to mark (highlight in a different color) symlinks in the crumb trail in Dolphin and have a context menu to resolve the symlink.

On the other hand, I'd personally like to know the root cause that brought up this idea - what was the exact scenario where the use of symlinks caused confusion? The examples given are overly simplistic and leave out details which would really be useful for determining why KDE should change the behavior. How much more helpful is it really to have Dolphin resolve symlinks (esp. from the point of view of someone who is familiar with them and used to the current/expected behavior)?

I'm not asking for a change, I'm asking for an option. Not even for a default option, just a plain option
Your idea of marking the crumb trail and provide a context menu to solve the symlink sounds good too.

airdrik explained this nicely and I agree with the others as well. What you are looking for is not a 'symbolic link' but a 'shortcut', as in, something that allows you to quickly move to a different point in the file system hierarchy, which is a completely different concept. Mixing them is not a good idea.

Ioannis wrote:airdrik explained this nicely and I agree with the others as well. What you are looking for is not a 'symbolic link' but a 'shortcut', as in, something that allows you to quickly move to a different point in the file system hierarchy, which is a completely different concept. Mixing them is not a good idea.

I still do not agree, there is no defined behavior behind symlinks, the application using them have fully the choice to resolve them or not, that's totally up to the application to decide what to do with them, in many shells you could have the choice to display the real path or the symlinked one in the prompts and in $PWD (expand option in tcsh for ex). This options should exists too in a file navigator like Dolphin, at least only for consistency if some people don't like to use this behavior (I do). Please let people have the choice, don't impose your point of view.

And please don't tell it's a windows point of view because I'm a Unix user for so long... and very rarely use windows. The shortcut concept instead come clearly from a windows point of view as it is not part of the Unix filesystems.

The default Dolphin behaviour is like the default behaviour of pwd and cd commands, which behaves as pwd -L and cd -L respectively. If one want them to utilize physical paths instead of logical, should type pwd -P and cd -P respectively. I think that Dolphin, as proudly a key KDE application, should have preferences to set that behaviour, because KDE applications usually are configurable (of course there are exceptions, like Apper and Amarok, which are too simple in terms of configuration). If even basic UNIX commands, pwd and cd, are configurable and one can set them to use physical or logical paths, typing explicitly switches or using aliases in ~/.bashrc, Dolphin also should be configurable that way.

I just found this thread while searching (hoping) for a way to show real paths in Dolphin. I don't know what Windows users do, but I have "set -P" in my .bashrc because I like the "teleport" model of directory navigation better than the virtual/illusory directory model. Making a .desktop file is an insufficient work-around. So I'd just like to endorse the original post: please offer something like the -P flag for Dolpin. Peace.

I add my just 2 cents to the question. I'm pro the possibility to add
a "cd -P" behavior (as optional) to symlinks.

The reason is that I use symlinks for two situations. The first is when I
need to make a local copy in a certain path of a directory or file
that is in other directory. But I do a symlink instead of copying the
file because this way I save space and also I don't duplicate
information; if I modify one of the files I modify the other. I think
that this is more like using the symlink as a hardlink, but with the
known advantages that symlinks have over hardlinks.

The other case is when I want to have some folder where I put work
directories, so that when I click on that icon (in Dolphin) I'm
teleported to that directory. In that case I want to follow the
symlink (i.e. "cd -P").

The ideal would be to right click on the symlink and
to have the option for choosing between the two behaviors.