From: "Pádraig Brady" <P@draigBrady.com>
To: Eric Blake <eblake@redhat.com>,
linux-api@vger.kernel.org, Alexander Viro <aviro@redhat.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: RFC: allow empty symlink targets
Date: Wed, 15 May 2013 21:48:53 +0100 [thread overview]
Message-ID: <5193F4B5.500@draigBrady.com> (raw)
In-Reply-To: <51939E49.1040209@redhat.com>
On 05/15/2013 03:40 PM, Eric Blake wrote:
> 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).
Ah OK. The standards are hard enough to interpret,
never mind the comments discussing the standards :)
Not helping was that symlink() returns ENOENT in this case too.
>> 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.
OK cool, that make more sense to me.
Adding in a couple more recipients to garner interest...
thanks,
Pádraig.
next prev parent reply other threads:[~2013-05-15 20:48 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-01-17 13:03 RFC: allow empty symlink targets Pádraig Brady
2013-01-17 13:03 ` [PATCH] symlink: allow an empty target string Pádraig Brady
2013-01-17 16:22 ` RFC: allow empty symlink targets Pádraig Brady
2013-05-15 12:38 ` Pádraig Brady
2013-05-15 14:40 ` Eric Blake
2013-05-15 20:48 ` Pádraig Brady [this message]
2013-05-24 10:01 ` Pavel Machek
2013-05-15 22:03 ` Al Viro
2013-05-16 9:37 ` Pádraig Brady
2013-05-16 12:22 ` Eric Blake
2013-05-26 9:39 ` Pavel Machek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5193F4B5.500@draigBrady.com \
--to=p@draigbrady.com \
--cc=aviro@redhat.com \
--cc=eblake@redhat.com \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox