Date: Tue, 19 Jun 2001 15:56:01 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Bakul Shah <bakul@bitblocks.com> Cc: current@FreeBSD.ORG, Matt Dillon <dillon@earth.backplane.com> Subject: Re: Ok, try this patch. (was Re: symlink(2) [Was: Re: tcsh.cat]) Message-ID: <Pine.BSF.4.21.0106191536440.14564-100000@besplex.bde.org> In-Reply-To: <200106181704.NAA12227@renown.cnchost.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0106191536440.14564-100000>