[lkml]   [2013]   [May]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: RFC: allow empty symlink targets
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
>>> 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:
> Following up from
> 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

[unhandled content-type:application/pgp-signature]
 \ /
  Last update: 2013-05-15 17:21    [W:0.099 / U:2.744 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site