Re: RFC: allow empty symlink targets

[Eric Blake]

On 05/15/2013 06:38 AM, PÃdraig Brady wrote:
> On 01/17/2013 04:22 PM, PÃdraig Brady wrote:
>> On 01/17/2013 01:03 PM, PÃdraig Brady wrote:
>>> The discussion leading to this is at http://bugs.gnu.org/13447
>>> In summary other systems allow an empty target for a symlink,
>>> and POSIX specifies that it should be allowed?
>>
>> In relation to this, Eric Blake said:
>>
>>> In today's Austin Group meeting, I was tasked to open a new bug that
>>> would state specifically how the empty symlink is resolved; the intent
>>> is to allow both Solaris behavior (current directory) and BSD behavior
>>> (ENOENT).  Meanwhile, everyone was in agreement that the Linux kernel
>>> has a bug for rejecting the creation of an empty symlink, but once that
>>> bug is fixed, then Linux can choose either Solaris or BSD behavior for
>>> how to resolve such a symlink.
>>>
>>> It will probably be a bug report similar to this one, which regarded how
>>> to handle a symlink containing just slashes:
>>> http://austingroupbugs.net/view.php?id=541
> 
> Following up from http://austingroupbugs.net/view.php?id=649
> It seems POSIX will now allow the current Linux behavior of returning ENOENT,

Huh?  Linux currently doesn't allow the creation of an empty symlink.
That link mentions the current BSD behavior of returning ENOENT when
resolving such a symlink (that is, what stat() does when chasing through
an empty symlink, provided such a symlink is first created).

> or the Solaris behavior of allowing empty symlink targets.

The point made in that bug report is that Linux is buggy for not
allowing symlink() to create an empty symlink in the first place; once
you allow the creation of an empty symlink, then how to handle such a
symlink in stat() is up to you whether to copy Solaris' or BSD's example.

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

Attachment: signature.asc
Description: OpenPGP digital signature