Symbolic links

[fanf]

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

Comments

[hoiho.livejournal.com]

Cygwin (on XP): ln: creating symbolic link `foo' to `': No such file or directory

NetBSD: As FreeBSD

[filecoreinuse.livejournal.com]

Does POSIX have a view on this?

[fanf]

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.

[crazyscot.livejournal.com]

OSX 10.3.9 - same as 10.4

[filecoreinuse.livejournal.com]

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.

[simont]

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.

[techiebloke.livejournal.com]

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

[zkzkz.livejournal.com]

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

[zkzkz.livejournal.com]

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
/tmp/foo
$ 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.

[zkzkz.livejournal.com]

(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.