How about offering to Show Target for directories and files that contain a symlink? Eg:
At the moment I can get Dolphin to Show Target for symlink_dir but there is no way to know the real path to symlink_dir/dir2/dir3/file which might be something like /dir0/dir1/dir2/dir3/file.
One practical problem I have all the time is that when I am in symlink_dir/dir2/dir3/file I can’t easily move upstream to dir1 with just a couple of clicks. I can’t edit the path either to replace symlink_dir with /dir0/dir1 because I may not know the real path, and even if I do it may be very long.
Show Target for every path that contains a symlink would solve this. That Target could show in Properties as well and users should be able to copy that, or there would be a button there that takes you to the real URL (Windows Explorer allows selecting and copying the URL).
I kind of understand your problem and at the same time I don’t. I think the whole point of symlinks is to easily make folders/files accessible through paths that make more sense to me, for example “soft mounting” my music folder into my home directory even though it’s on another hard drive. I personally don’t ever want to go back up to the original parent and don’t understand how your files need to be structured that you frequently have this problem, but I guess you have this use case.
One problem I can think of for implementing this as a feature is that dolphin might not know which folders are under a symlinked folder all the time without making extra file system calls which in turn could make navigation more IO inefficient for what is a pretty niche feature. It shouldn’t be a problem to show inside the properties dialog for just this one folder, though.
One quick solution for your case could be opening the terminal in dolphin in the current folder (F4) and typing “realpath .” which shows you the correct path which you can then copy and paste into dolphin’s location bar.
the properties dialog for the symlink has the realpath in a text box you can copy from and there is even a button next to it that will open the target directory in a separate tab for you in dolphin
I understood the problem to be not about the symlinked folder itself but about folders below it. So back to my music example: if I look at the properties for ~/music/Dj Konqi dolphin won’t tell me that it’s actually located at /mnt/harddrive/music/Dj Konqi, you only get that information when looking at ~/music/ itself
Here is one scenario I encounter all the time. I have a folder containing many symlinks to favourite folders and files. I could use Places but there are too many targets. I use one of those symlinks to get to a folder and then sometimes I find I should go one level up, say, from /path/to/dir1/dir2/dir3 to /path/to/dir1/dir2 but the path I see now is /path/to/symlink/dir3.
Using realpath in the terminal would work but it’s not efficient really. What I am suggesting really is adding the realpath functionality to the context menu, the address bar, and Properties. I don’t think it’s a niche feature. It may be just me, but I think it’s an obvious and peculiar omission. I don’t see why it would be a drain on resources either. It’s really the same as Show Target.
Well, I do think this is quite a particular use case, since most people would probably use dolphin’s bookmarking feature instead of keeping folders with what basically amounts to bookmark links. Although, since you’re only mentioning “places” you might not realize this feature exists? I have to admit it’s a bit hidden if you don’t expect it to exist, I had to look around for it myself a bit just now since I don’t usually need it myself. Actually, it seems kind of absent from the Global Menu for me? The easiest way to use it is to add “Bookmarks” to the buttons toolbar
Bookmarks would help but unless I miss something it doesn’t support files, only folders. Also, my method means I can add my favourites folder to the applications launcher, the desktop, Places etc, create a keyboard shortcut and more.
But anyway, this was just one example. In essence, I am saying that Show Target and realpath are useful and exist for a reason, and I don’t see why they shouldn’t work in dolphin for paths containing a symlink. Or why the user would have to jump through hoops to get that obvious piece information that a computer should really provide in Properties from day 1.
Well, you’re not wrong, I just tried to come up with an alternate solution to your troubles.
I’m all for adding “realpath” to file or folder properties if it differs from the “Location” field, although I’m not a fan of permanently extending the context menu since I feel it’s already big enough. I think a feature like this should be possible through an optional plugin?
I, too, dislike long and ever growing menus. With passion I would say. Adding ‘realpath’ to Properties and the Location bar context menu when useful would not add to the context menu. As for the context menu, the addition could be optional, possibly even opt-in. At the moment, IMV this is a glaring omission for a file explorer that has a well-deserved reputation for being super-flexible.
would simply adding an additional block of into to the properties dialog satisfy this need?
currently the properties of a linked to object show either the link path or the true path depending on which instance of the object you right click on.
if you right click on a linked to object it should add the info about the true path as shown
The way I see it currently Show Target is removed from the context menu when the selected object is not a symlink. Show Target could simply be retained if somewhere in the path of the object there is a symlink. The mechanism is already there. If people think it is too much, then by the same token Show Target could be removed altogether from the menu and leave Properties provide that information.
Adding Show Target to Properties in the bare minimum whether or not the context menu features Show Target.
One thing that will still be missing then is Show Target for the current folder. For that essential piece of information, Show Target could be added to the Location Bar context menu. I think this is the natural place for that.
the problem is this is exactly how symlinks are supposed to work.
when you look at anything below a symlink you are looking at it as tho the symlink folder were real…. so in my example, folder C would never know it didn’t belong to 1/B
the context menu in folder path says so.
the copy location Ctrl+Alt+C says so.
the properties dialog says so.
everything about the instance of folder C along the symlink path looks real once you are below the symlink… that’s the point of a symlink.
::
what you want to do runs counter to this idea
even adding the info to the properties dialog will require traversing the tree looking for symlinks (which takes time) in order to add the true path info.
then what to do if more than one symlink is found? which branch is the “true” branch?
and why does it even matter when whatever you do to anything below a symlink affects directly every other instance under any other symlinks as well as the true path item
when i add a text file to my symlink instance of folder C, the file also shows up in the true path instance so they are effectively on in the same, even tho their paths appear different.
What if you write a bash script that takes an argument and returns its real path? Then you could have the script display it in a dialog manager popup as an editabe field that you can copy it or even have the script copy it to the clipboard. Once you have the script, you can add it to the file type options for Open with and invoke it with an argumment such as %f (or a better option that I don’t have time to lookup RN) so Dolphin passes it the file name to the script. This is a bit rough-edged because I can’t try it out RN.
Neither Link Destination nor the Info Panel show the real path when the symlink is somewhere in the path rather than the selected object. Not restricting the current Show Target implementation is the obvious and user-friendly way to do this.
We can create scripts or use realpath in the terminal but among other things it goes against the idea that inexperienced users (eg Windows refugees) never ever need to open the scary terminal for something that is frankly basic information.
We are probably overthinking this. Show Target and realpath exist for good reasons. If we don’t believe this is the case, we might as well remove the current Show Target from the context menu and Properties for a more consistent and clutter-free approach.
The effort and resources to implement what already exists in Show Target and Properties to paths containing a symlink is minimal.
no, and neither does realpath so even if someone made a service menu to show it, it would still only show the path above it (including the symlink) and not the actual path directly to the file.
agreed.
once you are below a symlink, it is as if you were on the actual path… or to think of it another way, both the symlink path and the actual path are equally valid routes to get to where you are.
This is strange, although I may have misunderstood you.
I tried to run realpath and pwd in a normal directory inside a symlinked directory, and I can confirm that realpath does resolve the entire path, including symlinks in the upper levels, while pwd does not (as I would have expected).
What I found very strange, although slightly off-topic, is that when I ran both commands with strace to confirm the syscalls behaviors, both seemed to be unaware of the symlinked path, and appeared to only see the already resolved one. If anyone has any hint as to why this happens, I would be very curious (including possible mistakes on my side).
And continuing to look into it, I actually found that I am unable to make realpathnot resolve upper symlinks, even with realpath --no-symlinks. But this is now getting really off-topic.
Commenting on the actual issue, in my opinion it could be a “nice to have” feature, but definitely not essential. But I tend to use the terminal and coincidentally realpath a lot, so that is my tool.
However I can see the usefulness of conditionally show in the properties panel the real path of any element inside and/or below a symlinked directory, but I wouldn’t want to clutter the view too much. And I am afraid that this feature would be very niche.
Actually, it does. For /path/to/symlink/folder1/folder2/filerealpath returns: /real/path/to/folder1/folder2/file.
True, only there is a clear and unbreakable link between actual and symlinked folders and subfolders, hence the terms actual and real. There are legitimate reasons a user might want to jump from the symlink to the real/actual path (and back, I would argue), which is why realpath and the current restricted implementation of Show Target in Dolphin exist.
