Open CoSoCo opened 3 years ago
Current nemo version is 5.0.3...
Looking at https://www.gnu.org/software/coreutils/manual/html_node/ln-invocation.html#index-ln I didn't know you could have relative softlinks - but it seems very confusing except where the symlink and the target are in the same directory.
A simple absolute symlink:- ln -s target linkname
and if you move the target of a symlink you expect the link to break.
Apparently "Relative symbolic links are generated based on their canonicalized containing directory, and canonicalized targets". So that is straightforward isn't it?
Imagine you have a project in: /home/userA/ProjectX/ And inside this project there are some links with targets inside the project, e.g.: /home/userA/ProjectX/run -> /home/userA/ProjectX/build/bin/run If you copy the project to another user e.g.: /home/userB/ all absolute symlinks will target to the wrong files. This would not happen, if there have been relative symlinks. A similar problem will occur if you move the project, e.g.: /home/userA/ProjectX/ ==> /home/userA/projects/ProjectX/ All absolute symlinks will become invalid. Can you now see the advantage of relative symlinks?
If I copy/move a directory tree to another user then I would hope to see some permission problems!
However, if I copied /home/userA/ProjectX/
to /home/userB/ProjectX/
then a relative symlink in userA will access a different target to an identically named relative symlink in userB.
Some people would find this very confusing - especially if userA amended their target, but userB did not amend the equivalent destination.
So I can see the disadvantages of relative symlinks, indeed if you have an installation procedure it can always generate the correct absolute symlinks.
However, nobody is preventing you from using ln -rs
instead of ln -s
, should you insist upon it.
If I copy/move a directory tree to another user then I would hope to see some permission problems!
Of coarse you have to copy with appropriate rights. Or copy it to another location in your own HOME to try out some things. Or copy to a UBS-drive, and from there to another machine. Or ... etc. In all cases you would profit from relative symlinks.
However, if I copied /home/userA/ProjectX/ to /home/userB/ProjectX/ then a relative symlink in userA will access a different target to an identically named relative symlink in userB.
Correct. UserB can do things in his own tree without affecting the files of userA or conflicting with. userB has a consistent clone of the project of userA, He can use it for testing that version, and userA can make progress without affecting userB. Or userB can do changes without corrupting the original.
However, nobody is preventing you from using ln -rs instead of ln -s, should you insist upon it.
But the current state is preventing me to use a comfortable graphical tool.
It too enforces me to manually move and then rename (remove "Link to ") the created link in contrast to the convenient 2-step workflow I cited from here. The use case of a link in the same directory as the target is extremely rare.
Have you looked at the symlinks
package?
It may help...
Hm, from this point of view you can also ask, why using Nemo at all, because command line tools can do all, what one wants.
I wasn't suggesting that you stop using GUI tools, symlinks
can convert absolute links to relative links over a directory tree (amongst other abilities).
So it would be just a single command entered into the nemo terminal plugin.
Yes, and I can create a relative symlink from the beginning with a single ln
command (no need to "repair" it with symlinks
). That's not my point, my point is, that I want be able to create a relative symlink with the GUI right from the beginning with minimal count of actions.
Issue An absolute symlink becomes invalid if a filesystem tree is moved/copied to another location.
Steps to reproduce If I understand correct, Nemo's context menu item "Make Link" always creates an absolute symlink.
Expected behaviour Please create relative symlinks by default, if source and target are on the same volume, or maybe provide a suitable dialogue. In this case a 3rd option would be fine: offer a hardlink.
Other information As suggestion for an alternative design, please see: https://gitlab.gnome.org/GNOME/nautilus/-/issues/1901#note_1201115