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:
I guess you're looking for the -T (--no-target-directory) option...
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.
(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.
"-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?
(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.
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