bug#13447: ln "" foo gives misleading error message

[Pádraig Brady]

On 01/15/2013 09:31 AM, Jim Meyering wrote:
> Pádraig Brady wrote:
>
> > On 01/15/2013 08:23 AM, Ken Irving wrote:
> > > (Previously sent in error to the bug-gnu-utils list.)
> > >
> > > 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.
> >
> > We're just reporting what the operating system returns here:
> >
> > $ python -c 'import os; os.symlink("","tl")'
> > Traceback (most recent call last):
> >    File "<string>", line 1, in <module>
> > OSError: [Errno 2] No such file or directory
> >
> > Interestingly I notice that solaris for example allows a NULL old_path.
>
> That Solaris behavior is contrary to POSIX 2008
> http://pubs.opengroup.org/onlinepubs/9699919799/functions/symlink.html

The POSIX ENOENT description only mentions the empty path2 case.
I.E. the empty symlink name, which as expected would return ENOENT.

> If someone is motivated, this suggests a symlink wrapper
> in gnulib would be welcome: it would make it so even on
> Solaris, symlink(any, "") would fail with the required ENOENT.
>
> > I suppose we could handle this case specially like:
> >
> >    if (errno == ENOENT && !*old_path)
> >      error(...,"An empty target is not supported on this system");
>
> s/supported.*/portable|valid/?
>
> > Though I'm not sure there's much benefit in a specific
> > error message in this case?
>
> I could go either way.
> There is precedent, but it's such a corner case,
> it may not be worth the added code.

given the confusion above, it might be worth the
clarification error message.

thanks,
Pádraig.