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

[Geoff Clare]

Eric Blake <address@hidden> wrote, on 15 Jan 2013:
>
> [adding the Austin Group]
> 
> On 01/15/2013 02:58 AM, Jim Meyering wrote:
> 
> >>> That Solaris behavior is contrary to POSIX 2008
> >>> http://pubs.opengroup.org/onlinepubs/9699919799/functions/symlink.html
> >>
> >> Where does it say this?  I read it through in detail but I didn't see
> >> that it required a diagnostic to be emitted in the case that value is
> >> am empty string.  What did I miss?
> > 
> > Oh!  You're right.  Thanks for pointing that out.
> > It's only the source (2nd argument) to symlink that may not
> > be the empty string.
> 
> I also checked POSIX 2008 TC1 (in the middle of ratification process),
> and while it altered the wording, it still mentions only path2:
> 
> On Page: 2058 Line: 65095 Section: symlink()
> In the ERRORS section, change the [ENOENT] error from:
> [ENOENT] A component of path2 does not name an existing file or
> path2 is an empty string.
> to:
> [ENOENT] A component of the path prefix of path2 does not name an
> existing file or path2 is an empty string.
> [ENOENT] or [ENOTDIR]
> The path2 argument contains at least one non-<slash> character and ends
> with one or more trailing <slash> characters. If path2 names an existing
> file, an [ENOENT] error shall not occur.
> Rationale: Austin Group Defect Report(s) applied: 146,428,436.
> See http://austingroupbugs.net/view.php?id=146
> See http://austingroupbugs.net/view.php?id=428
> See http://austingroupbugs.net/view.php?id=436
> 
> What do others on the Austin Group think about an empty string for path1
> in symlink()?

The 2nd paragraph of the description clearly states:

    The string pointed to by path1 shall be treated only as a
    character string and shall not be validated as a pathname.

An implementation which gives an ENOENT error for an empty path1 string
is treating the string as a pathname and therefore does not conform.

> Current Linux rejects the symlink() call with ENOENT;
> FreeBSD 8.2 allows it but refuses to resolve the symlink ("ln -s '' a &&
> ls a/" reports ENOENT); Solaris 10 allows it and resolves the symlink as
> though it were '.' ("ln -s '' a && ls a/" reports the current directory
> contents).

Presumably if you follow the pathname resolution rules to the letter
you will end up with either the FreeBSD or the Solaris behaviour
being the required one.  Of course, whichever one it is, that may
be an accidental outcome of the way the pathname resolution section
is written rather than an intention to disallow the other behaviour.

-- 
Geoff Clare <address@hidden>
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England