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

[Eric Blake]

[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()?  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).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature