Log in

No account? Create an account


Symbolic links

« previous entry | next entry »
15th Sep 2008 | 14:40

What happens if you try to create a symlink to a zero-length target, as in ln -s "" foo?

Linux: ENOENT.

Mac OS X 10.4: EINVAL.

FreeBSD: works, and any attempt to resolve the symlink returns ENOENT.

Solaris: works, and the resulting symlink behaves the same as ln -s . foo

| Leave a comment |

Comments {9}


from: filecoreinuse
date: 15th Sep 2008 15:55 (UTC)

Does POSIX have a view on this?

Reply | Thread

Tony Finch

from: fanf
date: 15th Sep 2008 16:06 (UTC)

I think the relevant sentence is:

The string pointed to by [the first argument] shall be treated only as a character string and shall not be validated as a pathname.

Which implies that FreeBSD and Solaris are correct to create the symlink and the others do not conform to POSIX. The pathname resolution algorithm explains how to interpret symlinks, and it is described in terms of string concatenation in a way that agrees with Solaris not FreeBSD. On the other hand my intuition agrees with FreeBSD.

Edited at 2008-09-15 04:13 pm (UTC)

Reply | Parent | Thread


from: crazyscot
date: 15th Sep 2008 15:56 (UTC)

OSX 10.3.9 - same as 10.4

Reply | Thread


from: filecoreinuse
date: 15th Sep 2008 16:31 (UTC)

Briefly looking at the symlink syscall in Linux at http://lxr.linux.no/linux+v2.6.26.5/fs/namei.c#L2447 it appears that the 'Right Thing' is done in that the first path is just passed 'as is' to the VFS layer meaning buggy behaviour can be blamed on the FS driver. This all assumes that GNU's libc doesn't 'sanitise' the input.

Reply | Thread

Simon Tatham

from: simont
date: 15th Sep 2008 16:46 (UTC)

A quick strace ln -s "" zzz turns up
symlink("", "zzz")                      = -1 ENOENT (No such file or directory)
so it doesn't look as if glibc is doing anything obviously silly above the syscall level.

Reply | Parent | Thread

from: techiebloke
date: 15th Sep 2008 16:57 (UTC)

It might be interesting, then, to repeat the linux experiment with a variety of filesystems: eg UFS.

Reply | Parent | Thread


from: zkzkz
date: 15th Sep 2008 20:10 (UTC)

Huh, fascinating. My intuition led me to expect Solaris's behaviour.

Reply | Thread


from: zkzkz
date: 15th Sep 2008 20:14 (UTC)

So in trying to justify my intuition I found what I would consider a bug in Bash -- "set -P" shouldn't change the user-visible behaviour of "cd":

$ pwd
$ cd ""
$ set -P
$ cd ""
bash: cd: : No such file or directory

But really this is caused by the same disagreement. Bash is behaving as I would expect and assuming chdir("") is a noop. But Linux apparently gives an error.

Reply | Parent | Thread


from: zkzkz
date: 15th Sep 2008 20:16 (UTC)

(Well, except for the way it's documented to, namely the behaviour of ".." of course)

What an abomination, I wonder why I haven't turned it off yet.

Reply | Parent | Thread