ln "" foo gives misleading error message

[Ken Irving]

I've been using symbolic links in a non-file-related way, e.g., to store
arbitrary string values, but find that if I try to create a symlink with
an empty 'target' name, e.g., as 'ln -s "" foo', the error message emitted
is not really correct.

$ ln -s "" foo
ln: creating symbolic link `foo' -> `': No such file or directory
$ ln -sf "" foo
ln: creating symbolic link `foo' -> `': No such file or directory

A link can be created when no file or directory exists, e.g.,

$ stat x || ln -s x foo && echo ok
stat: cannot stat `x': No such file or directory
ok

so it seems that 'No such file or directory' must not be the actual
reason for the failure. Perhaps something like 'null target name'
would be more accurate?

I only happened upon this in working on a test script, and have no
expectation for the operation to succeed.

Thanks

Ken Irving

[Bob Proulx]

Ken Irving wrote:
> I've been using symbolic links in a non-file-related way, e.g., to store
> arbitrary string values,

Sure. This is done by many programs. Such as Emacs and Firefox for
example which both store lock information. And others too. It is
quite a commonly done technique.

> but find that if I try to create a symlink with an empty 'target'
> name, e.g., as 'ln -s "" foo', the error message emitted is not
> really correct.
>
> $ ln -s "" foo
> ln: creating symbolic link `foo' -> `': No such file or directory
> $ ln -sf "" foo
> ln: creating symbolic link `foo' -> `': No such file or directory

That error message comes from the kernel. I agree that it isn't
really correct. But if that is to be improved it would need to be the
kernel that would need to improve it.

I ran it with strace to report what the kernel returned.

$ strace -v -e symlink ln -s "" foo
symlink("", "foo") = -1 ENOENT (No such file or directory)

ln: creating symbolic link `foo' -> `': No such file or directory

It can be seen the "ln" program is simply reporting what the kernel
returned to it as errno. The kernel returned -1 indicating failure
and set errno to ENOENT as to why.

> A link can be created when no file or directory exists, e.g.,
>
> $ stat x || ln -s x foo && echo ok
> stat: cannot stat `x': No such file or directory
> ok

That is just fine. The value of the symlink can be an arbitrary
value. Although I admit I didn't know it couldn't be a zero length
string until you mentioned it. I only tested the Linux kernel. I now
want to test other kernels. In particular BSD would be the gold
standard reference for symlinks since they were developed there.

> so it seems that 'No such file or directory' must not be the actual
> reason for the failure. Perhaps something like 'null target name'
> would be more accurate?

On first thought I think it should be allowed. Although it is an
unusual use to store nothing there. How would that be interpreted as
a file? Would it be the same as "."? Perhaps the kernel authors were
simply avoiding that question of defining what to do with a zero
length value for the symlink. Allowing it may open more problems than
they wanted to deal with and simply using ENOENT perhaps the simplest
error to return in that case.

> I only happened upon this in working on a test script, and have no
> expectation for the operation to succeed.

Posting this here in bug-gnu-utils is of course good. However just
for reference the "ln" program is part of the coreutils project. If
you would like to discuss this with the coreutils developers directly
(since only a few of them are subscribed here) the discussion list for
it would be the core...@gnu.org mailing list.

Bob

[Ken Irving]

I don't have any particular reason to want to store a zero-length value,
but just found the error message message misleading, especially after
working with lots of 'bad' or 'dangling' symlinks which behave just fine.

> > I only happened upon this in working on a test script, and have no
> > expectation for the operation to succeed.
>
> Posting this here in bug-gnu-utils is of course good. However just
> for reference the "ln" program is part of the coreutils project. If
> you would like to discuss this with the coreutils developers directly
> (since only a few of them are subscribed here) the discussion list for
> it would be the core...@gnu.org mailing list.

Oops. I did see that it was in the coreutils package, but somehow
got off track to post here after a bit of googling. I resent the same
message there, but not sure if I should cc this reply there as well...

Thanks for your help in digging into this.

Ken

--
Ken.Irving

[Bob Proulx]

Ken Irving wrote:

> Bob Proulx wrote:
> > Posting this here in bug-gnu-utils is of course good. However just
> > for reference the "ln" program is part of the coreutils project. If
> > you would like to discuss this with the coreutils developers directly
> > (since only a few of them are subscribed here) the discussion list for
> > it would be the core...@gnu.org mailing list.
>
> Oops. I did see that it was in the coreutils package, but somehow
> got off track to post here after a bit of googling. I resent the same
> message there, but not sure if I should cc this reply there as well...

Sending it here to bug-gnu-utils was of course perfectly fine since ln
is one of the GNU utils and this is a good list for it. But sending
it to bug-coreutils was not good since it isn't a bug in ln and
opening a bug ticket there is silly. Especially since you already
have the answer here. And especially since I already said that the
mailing list for discussion was core...@gnu.org instead.

Bob

[Andreas Schwab]

Bob Proulx <b...@proulx.com> writes:

> That error message comes from the kernel. I agree that it isn't
> really correct. But if that is to be improved it would need to be the
> kernel that would need to improve it.

IMHO it is a kernel bug to give an error here. The symlink target shall
not be parsed at symlink creation, and POSIX does not place any
restriction on it apart from the maximum length.

> On first thought I think it should be allowed. Although it is an
> unusual use to store nothing there. How would that be interpreted as
> a file? Would it be the same as "."?

An empty name never resolves to a file, so any attempt to follow this
symlink should fail with ENOENT (but not the symlink creation).

> Perhaps the kernel authors were simply avoiding that question of
> defining what to do with a zero length value for the symlink.
> Allowing it may open more problems than they wanted to deal with and
> simply using ENOENT perhaps the simplest error to return in that case.

Since the symlink target needs to be parsed every time the link is
followed I don't see how this can create more problems.

Andreas.

--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[Bob Proulx]

Andreas Schwab wrote:
> IMHO it is a kernel bug to give an error here. The symlink target shall
> not be parsed at symlink creation, and POSIX does not place any
> restriction on it apart from the maximum length.

Agreed. So far I can't think of any reason not to allow an empty
string there. Seems like a kernel bug.

> An empty name never resolves to a file, so any attempt to follow this
> symlink should fail with ENOENT (but not the symlink creation).
>
> > Perhaps the kernel authors were simply avoiding that question of
> > defining what to do with a zero length value for the symlink.
> > Allowing it may open more problems than they wanted to deal with and
> > simply using ENOENT perhaps the simplest error to return in that case.
>
> Since the symlink target needs to be parsed every time the link is
> followed I don't see how this can create more problems.

After some thinking I agree with you. It would be just the same as if
an empty string were given for the original file.

Seems like a Linux kernel bug.

Bob

[John Cowan]

Andreas Schwab scripsit:

> An empty name never resolves to a file, so any attempt to follow this
> symlink should fail with ENOENT (but not the symlink creation).

On Solaris 9, an empty symbolic link can be freely created, and it
resolves to the current working directory, as does an attempt to open
"" directly. On Cygwin, attempting to create a zero-length symbolic
link fails with ENOENT, just as on Linux.

--
John Cowan co...@ccil.org http://ccil.org/~cowan
I am he that buries his friends alive and drowns them and draws them
alive again from the water. I came from the end of a bag, but no bag
went over me. I am the friend of bears and the guest of eagles. I am
Ringwinner and Luckwearer; and I am Barrel-rider. --Bilbo to Smaug