Bug 573377

Summary: ln -sf does not work
Product: [Fedora] Fedora Reporter: Wolfgang Denk <wd>
Component: coreutilsAssignee: Ondrej Vasik <ovasik>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: low    
Version: 12CC: kdudka, ovasik, twaugh
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-03-14 12:34:12 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Wolfgang Denk 2010-03-14 10:09:55 EDT
Description of problem:

"ln -sf" fails in certain situations silently.

Version-Release number of selected component (if applicable):

Fedora 12 / coreutils-7.6-9.fc12.i686

How reproducible:

Always.

Steps to Reproduce:
1. $ mkdir foo bar
2. $ ln -s foo baz
3. Verify:
        $ ls -ld foo bar baz
        drwxr-xr-x 2 wd users 6 Mar 14 15:02 bar
        lrwxrwxrwx 1 wd users 3 Mar 14 15:02 baz -> foo
        drwxr-xr-x 2 wd users 6 Mar 14 15:02 foo
        $ ls -l foo bar
        bar:
        total 0

        foo:
        total 0
4. $ ln -s -f bar baz

  
Actual results:

No error raised. "baz" still pointing to "foo".
"foo" now contains anew symboic link "bar" pointing to itself:

        $ ls -ld foo bar baz
        drwxr-xr-x 2 wd users  6 Mar 14 15:02 bar
        lrwxrwxrwx 1 wd users  3 Mar 14 15:02 baz -> foo
        drwxr-xr-x 2 wd users 16 Mar 14 15:05 foo
        $ ls -l foo bar
        bar:
        total 0

        foo:
        total 0
        lrwxrwxrwx 1 wd users 3 Mar 14 15:05 bar -> bar

Expected results:

My expectation is that the result of "ln -s -f target link_name" is the same
as that of "rm -f link_name; ln -s target link_name".

In this case I exoect that the symbolic link "baz" gets removed and a new one created, pointing to "bar" similar to this:
        $ rm -f baz
        $ ln -s bar baz
        $ ls -ld foo bar baz
        drwxr-xr-x 2 wd users 6 Mar 14 15:09 bar
        lrwxrwxrwx 1 wd users 3 Mar 14 15:09 baz -> bar
        drwxr-xr-x 2 wd users 6 Mar 14 15:08 foo
        $ ls -l foo bar baz
        lrwxrwxrwx 1 wd users 3 Mar 14 15:09 baz -> bar

        bar:
        total 0

        foo:
        total 0


Additional info:
Comment 1 Kamil Dudka 2010-03-14 10:13:56 EDT
I guess you're looking for the -T (--no-target-directory) option...
Comment 2 Wolfgang Denk 2010-03-14 11:25:57 EDT
I don't see how "-T" wouldbe related. Unless I'm missing something, the documentation mentions it only for the case where the last argument is a directory name (and "directory" is someting different than "symbolic link pointing to a directory"). Here this is not the case - the last argument is the name of the link that shall be created (and may already exist).

The bug is that "ln" follows the link. It should not do that.
Comment 3 Kamil Dudka 2010-03-14 12:34:12 EDT
(In reply to comment #2)
> I don't see how "-T" wouldbe related. Unless I'm missing something, the

Just try -T with your reproducer, it gives you the expected result, doesn't it?

> The bug is that "ln" follows the link. It should not do that.

It's not a bug since it works as documented.  See the ln(1) info page for more details.  What exactly is the problem in using -T?  You can also consider the -n (--no-dereference) option, which is weaker than -T.
Comment 4 Wolfgang Denk 2010-03-14 14:55:00 EDT
"-T" is not portable. As far as I can tell it is specific to the GNU implementation of the "ln" command - i. e. it does not work on any of the BSD systems.

Is "-T" POSIX conformant?
Comment 5 Kamil Dudka 2010-03-14 15:08:26 EDT
(In reply to comment #4)
> "-T" is not portable. As far as I can tell it is specific to the GNU
> implementation of the "ln" command - i. e. it does not work on any of the BSD
> systems.

Then use the '-n' instead, if it does the job for you.  Anyway the genuine ln(1) implementation on BSD without any options works in the same way as the GNU coreutils' ln(1).  So there is not much we can do with the default behavior.

On FreeBSD 8.0-STABLE I can see '-n' as equivalent of the '-h' option.

> Is "-T" POSIX conformant?

AFAIK, none of them is.
Comment 6 Kamil Dudka 2010-03-16 04:31:49 EDT
Here is some context from an independently reported "notabug" on the upstream mailing-list:

http://lists.gnu.org/archive/html/bug-coreutils/2010-03/msg00173.html