Bug 29115 - 'ln -sr' always dereference target
Summary: 'ln -sr' always dereference target
Status: CLOSED WONTFIX
Alias: None
Product: Sisyphus
Classification: Development
Component: coreutils (show other bugs)
Version: unstable
Hardware: all Linux
: P3 normal
Assignee: placeholder@altlinux.org
QA Contact: qa-sisyphus
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-06-26 20:55 MSK by led
Modified: 2017-10-28 04:33 MSK (History)
5 users (show)

See Also:

Attachments
fix 'ln --relative' for no dereference target by default (606 bytes, patch)
2013-06-26 20:55 MSK, led 		no flags Details | Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description led 2013-06-26 20:55:32 MSK 
Created attachment 5860 [details]
fix 'ln --relative' for no dereference target by default

$ ln -sr /etc/X11/lib64/libGL.so.1 /tmp/libGL.so.1
$ readlink /tmp/libGL.so.1
../usr/lib64/X11/libGL.so.1.2

что вовсе не то, предполагалось.
Т.е. '-r' всегда работает, как будто присутсвует '-L'

Приложенный патч вроде бы решает это, делая dereference для target только если указан '-L'
Comment 1 Michael Shigorin 2013-07-09 20:35:27 MSK 
ping
Comment 2 Dmitry V. Levin 2013-07-18 04:04:16 MSK 
I forwarded this to coreutils mailing list and received a reply:
http://lists.gnu.org/archive/html/coreutils/2013-07/msg00053.html

In short, the issue was already discussed at
http://lists.gnu.org/archive/html/coreutils/2012-02/msg00167.html,
"ln -rs" is not going to change anyway, and even the change to "ln -Prs" is unlikely to be accepted because of ambiguity.

For greater control, they suggest using realpath(1) in conjunction with ln(1) without -r.
Comment 3 Dmitry V. Levin 2017-10-28 04:33:36 MSK 
wontfix upstream