On Sat, 23 Jun 2001, Matt Dillon wrote:
> Ok, Bruce... the symlink patch has been sitting in my tree for a week
> now. I am going to let you decide whether I should commit it or not.
> If not, into the trash heap it goes. This is likely to be the only
> way the problem will be s
Ok, Bruce... the symlink patch has been sitting in my tree for a week
now. I am going to let you decide whether I should commit it or not.
If not, into the trash heap it goes. This is likely to be the only
way the problem will be solved since creating an empty symlink via
the
> > So it seems to me the _use_ of a "" target symlink
> > (in all but the final path component position) is exactly
> > equivalent to the use of a "/" target symlink. When used in
> > the final path component position, you get either the symlink
> > or ENOENT. The POSIX excerpt Garrett quoted s
On Mon, 18 Jun 2001, Bakul Shah wrote:
> > NetBSD committed essentially this patch 4 years ago (as part of rev.1.23).
> > I like it, except it seems to be incompatible with POSIX.1-200x.
>
> > ... [not what "not quite" applies to]
>
> Err... not quite. Given a path like
> /
> after the sub
<
said:
> In anycase, I can't imagine that POSIX actually intended null
> symlinks to act in any particular way
The standard specifies precisely how pathname resolution is supposed
to behave. FreeBSD should conform to the standard, even if some of
the consequences are somewhat unexpected. (At
:< said:
:
:>> > ./foo/ .//
:>> > ./foo/bar .//bar
:>>
:>> No, because the ``resulting filename'' begins with a slash.
:
:> It seems resulting filename (pathname?) begins with "./" (not a slash).
:
:No, it doesn't. The ``resulting filename'' is "/" in the first case,
:and "/b
< said:
>> >./foo/ .//
>> >./foo/bar .//bar
>>
>> No, because the ``resulting filename'' begins with a slash.
> It seems resulting filename (pathname?) begins with "./" (not a slash).
No, it doesn't. The ``resulting filename'' is "/" in the first case,
and "/bar" in the
On Mon, Jun 18, 2001 at 13:22:10 -0400, Garrett Wollman wrote:
> < said:
>
> > Maybe it is just my bad English understanding, but it seems last two cases
> > must be
> > ./foo/ .//
> > ./foo/bar .//bar
>
> No, because the ``resulting filename'' begins with a slash.
It see
< said:
> Maybe it is just my bad English understanding, but it seems last two cases
> must be
> ./foo/ .//
> ./foo/bar .//bar
No, because the ``resulting filename'' begins with a slash.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe fre
> NetBSD committed essentially this patch 4 years ago (as part of rev.1.23).
> I like it, except it seems to be incompatible with POSIX.1-200x.
> The bug that stat(2) on a null symlink classifies the target of the symlink
> as a directory is caused by resolving the pathname to "" and then not
> r
On Mon, Jun 18, 2001 at 11:53:59 -0400, Garrett Wollman wrote:
> < said:
>
> > NetBSD committed essentially this patch 4 years ago (as part of rev.1.23).
> > I like it, except it seems to be incompatible with POSIX.1-200x.
>
> I think I agree with your interpretation. Quoting from XBDd7, page
>
< said:
> NetBSD committed essentially this patch 4 years ago (as part of rev.1.23).
> I like it, except it seems to be incompatible with POSIX.1-200x.
I think I agree with your interpretation. Quoting from XBDd7, page
101, lines 3153ff:
# In all other cases, the system shall prefix the remain
On Sun, 17 Jun 2001, Matt Dillon wrote:
> Ok, this patch should do it. For review. I've made it return ENOENT,
> which is the same error that is returned when you try to open an empty
> path (e.g. open("", ...)).
>
> (Note: This is unrelated to Bruce's second issue with 'cp' co
13 matches
Mail list logo
