[SOLVED] ln -sf does not work with a directory target, but ln -nsf does.

Richard Cranium · 11-17-2011, 09:17 PM

Maybe all of you already knew this tidbit, but I had never figured it out until today, thanks to this thread somewhere else.

Frankly, I can't imagine a scenario where issuing...

Code:

ln -sf source_dir target_dir

should do anything different from...

Code:

ln -nsf source_dir target_dir

...but maybe that's due to my lack of imagination.

Can any of you think of a reason why ln -sf works in such a *bleeped* up way with directories by default?

Alien Bob · 11-18-2011, 02:16 AM

For me, the two commands give identical results in all test cases, working with directories as link targets.
Can you give some examples?

Eric

GazL · 11-18-2011, 05:34 AM

Yes, this one used to catch me out regularly too when replacing an existing link. Used to see it most often with the /usr/src/linux symlink

example

Code:

gazl@slack:/tmp$ mkdir linux-5.0.0 linux-5.0.1
gazl@slack:/tmp$ ln -sf linux-5.0.0 linux
gazl@slack:/tmp$ ls -l
total 0
lrwxrwxrwx 1 gazl users 11 Nov 18 11:27 linux -> linux-5.0.0
drwxr-xr-x 2 gazl users 40 Nov 18 11:27 linux-5.0.0
drwxr-xr-x 2 gazl users 40 Nov 18 11:27 linux-5.0.1
gazl@slack:/tmp$ ln -sf linux-5.0.1 linux
gazl@slack:/tmp$ ls -l
total 0
lrwxrwxrwx 1 gazl users 11 Nov 18 11:27 linux -> linux-5.0.0
drwxr-xr-x 2 gazl users 60 Nov 18 11:28 linux-5.0.0
drwxr-xr-x 2 gazl users 40 Nov 18 11:27 linux-5.0.1
gazl@slack:/tmp$ ls -l linux-5.0.1
total 0
gazl@slack:/tmp$ ls -l linux-5.0.0
total 0
lrwxrwxrwx 1 gazl users 11 Nov 18 11:28 linux-5.0.1 -> linux-5.0.1

I work around this by using the '-T' option rather than '-n', which seems more correct in this particular example.

Without this option ln assumes that you want to put the symlink in the existing target directory, which is not unreasonable when you thinki about it, but it does catch you out if you're not aware of this little quirk.

Richard Cranium · 11-19-2011, 01:59 AM

Quote:

Originally Posted by Alien Bob

For me, the two commands give identical results in all test cases, working with directories as link targets.
Can you give some examples?

Eric

Sure!

Code:

bash-4.1$ mkdir one
bash-4.1$ mkdir two
bash-4.1$ ls -l
total 0
drwxrwxr-x 2 notroot users 6 Nov 19 01:55 one/
drwxrwxr-x 2 notroot users 6 Nov 19 01:55 two/
bash-4.1$ ln -s one test
bash-4.1$ ls -l
total 0
drwxrwxr-x 2 notroot users 6 Nov 19 01:55 one/
lrwxrwxrwx 1 notroot users 3 Nov 19 01:55 test -> one/
drwxrwxr-x 2 notroot users 6 Nov 19 01:55 two/
bash-4.1$ ln -sf two test
bash-4.1$ ls -l
total 0
drwxrwxr-x 2 notroot users 16 Nov 19 01:55 one/
lrwxrwxrwx 1 notroot users  3 Nov 19 01:55 test -> one/
drwxrwxr-x 2 notroot users  6 Nov 19 01:55 two/
bash-4.1$ ln -nsf two test
bash-4.1$ ls -l
total 0
drwxrwxr-x 2 notroot users 16 Nov 19 01:55 one/
lrwxrwxrwx 1 notroot users  3 Nov 19 01:55 test -> two/
drwxrwxr-x 2 notroot users  6 Nov 19 01:55 two/
bash-4.1$ cat /etc/slackware-version 
Slackware 13.37.0
bash-4.1$

Richard Cranium · 11-19-2011, 02:37 AM

Quote:

Originally Posted by GazL

I work around this by using the '-T' option rather than '-n', which seems more correct in this particular example.

Without this option ln assumes that you want to put the symlink in the existing target directory, which is not unreasonable when you think about it, but it does catch you out if you're not aware of this little quirk.

I hadn't thought of it that way. Even so, the resulting symlink is useless when you link directories like that...

Code:

bash-4.1$ mkdir one
bash-4.1$ mkdir two
bash-4.1$ ln -s one test
bash-4.1$ ls -l
total 0
drwxrwxr-x 2 notroot users 6 Nov 19 02:10 one/
lrwxrwxrwx 1 notroot users 3 Nov 19 02:10 test -> one/
drwxrwxr-x 2 notroot users 6 Nov 19 02:10 two/
bash-4.1$ ln -sf two test
bash-4.1$ ls -l
total 0
drwxrwxr-x 2 notroot users 16 Nov 19 02:11 one/
lrwxrwxrwx 1 notroot users  3 Nov 19 02:10 test -> one/
drwxrwxr-x 2 notroot users  6 Nov 19 02:10 two/
bash-4.1$ cd test
bash-4.1$ ls -l
total 0
lrwxrwxrwx 1 notroot users 3 Nov 19 02:11 two -> two
bash-4.1$ cd two
bash: cd: two: Too many levels of symbolic links
bash-4.1$

...so it seems to me that this is broken behavior. But, since a symlink is simply text that is resolved later, maybe the -T option is the best they could do. Thanks for the tip!

wildwizard · 11-19-2011, 03:25 AM

Quote:

Originally Posted by Richard Cranium

I hadn't thought of it that way. Even so, the resulting symlink is useless when you link directories like that...

Code:

bash-4.1$ ln -sf two test
lrwxrwxrwx 1 notroot users 3 Nov 19 02:11 two -> two

Note that you created a symlink to itself, if you did

Code:

ln -sf /full/path/two test

or

Code:

ln -sf ../two test

Then it does work

Richard Cranium · 11-20-2011, 11:09 PM

Fair enough; that was a use case that I hadn't tried.

wildwizard · 11-21-2011, 03:29 AM

I should extend this to say that the target for the symlink does not have to exist at the time of creation, the path to the target may also not resolve from the current directory but may resolve from the destination directory, which is the case I illustrated.

This is mentioned in brief in the man page for ln
When creating hard links, each TARGET must exist. Symbolic links can hold arbitrary text; if later resolved, a relative link is interpreted in relation to its parent directory.

The section in bold basically means you can tell ln to create the symlink with whatever data you feel like, powerful but dangerous.

Richard Cranium · 11-22-2011, 01:22 AM

I'm going to mark this thread as solved. Thanks again to all of you who posted!