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
>     <prefix>/<symlink><suffix>
> after the substitution of <symlink> with its target, the
> search must start at the root if <symlink> target starts with
> a "/".

This is the most critical point.

> 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 seems to match
> this.

No, because the relevant slash is in the pathname resulting from
simple replacement of the full path prefix (<prefix>/<symlink>)
with the symlink's contents.  Quoting Garrett's quote:

> I think I agree with your interpretation.  Quoting from XBDd7, page
> 101, lines 3153ff:
> # In all other cases, the system shall prefix the remaining pathname,
> # if any, with the contents of the symbolic link. [...]  [T]he
> # resolved pathname shall be the resolution of the pathname just
> # created.  If the resulting pathname does not begin with a slash, the
> # predecessor of the first filename of the pathname is taken to be the
> # directory containing the symbolic link.

When the string symlink's contents is null, the resulting pathname is
<suffix>, and this always begins with a slash (since there wouldn't
be a suffix without a slash).

> This is surprising at first but hardly worth adding a
> singularity (an exception).  So IMHO for a "" target symlink

The consequences of the standard are surprising at second :-).  I wonder
if surprising things also happen for suffixes beginning with 2 slashes?
2 slashes in the middle of the pathname are normally equivalent to a
single slash, but if the quoted pathname resolution occurs before slash
combination (I haven't read the standard carefully enough to know
whether it does), then a null symlink pushes the double slash to the
beginning of the pathname where it may have special meaning.  A leading
double slash also occurs when the symlink's contents is "/", and in this
case the slashes can't be combined earlier.

> This is not a big deal but I care about not having
> unnecessary exceptions.

Me too.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to