From owner-freebsd-current Mon Jun 18 22:58: 3 2001 Delivered-To: freebsd-current@freebsd.org Received: from mailman.zeta.org.au (mailman.zeta.org.au [203.26.10.16]) by hub.freebsd.org (Postfix) with ESMTP id BD0BC37B401 for ; Mon, 18 Jun 2001 22:57:58 -0700 (PDT) (envelope-from bde@zeta.org.au) Received: from bde.zeta.org.au (bde.zeta.org.au [203.2.228.102]) by mailman.zeta.org.au (8.9.3/8.8.7) with ESMTP id PAA21770; Tue, 19 Jun 2001 15:57:52 +1000 Date: Tue, 19 Jun 2001 15:56:01 +1000 (EST) From: Bruce Evans X-Sender: bde@besplex.bde.org To: Bakul Shah Cc: current@FreeBSD.ORG, Matt Dillon Subject: Re: Ok, try this patch. (was Re: symlink(2) [Was: Re: tcsh.cat]) In-Reply-To: <200106181704.NAA12227@renown.cnchost.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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 substitution of with its target, the > search must start at the root if 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 (/) 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 , 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