Re: ln "" foo gives misleading error message

[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 address@hidden mailing list.

Bob