Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!necntc!ames!amdahl!cerebus!fai!wjvax!brett
From: brett@wjvax.UUCP (Brett Galloway)
Newsgroups: comp.unix.wizards
Subject: Re: Symbolic Links
Message-ID: <1014@wjvax.wjvax.UUCP>
Date: Fri, 11-Sep-87 12:16:58 EDT
Article-I.D.: wjvax.1014
Posted: Fri Sep 11 12:16:58 1987
Date-Received: Sat, 19-Sep-87 01:16:48 EDT
References: <2931@ulysses.homer.nj.att.com> <1817@munnari.oz> <2934@ulysses.homer.nj.att.com>
Reply-To: brett@wjvax.UUCP (Brett Galloway)
Organization: Watkins-Johnson Co., San Jose, Calif.
Lines: 21

I have listened (read) this discussion for quite a while, and one thing
that has bothered me with the anti-bsd-symlinks position is one of
consistency.  Making '..` return along the path that was originally
traversed is fine, as long as that can be unambiguously determined.  In
the context of the cd command (chdir(2)), it can be.  However, there are many
other cases where the cd command is not used, but similar behaviour is
expected.  For example, the path

	/u/foo/bar/../file

could reasonably be expected to reference /u/foo/file.  However, if the
path state information is bound only to the cd command, this won't work.
In order to be consistent, *two* sets of state information must be retained.
One for the cd command (to apply across *different* system calls), and one
for path resolution, to be used *within* a system call.

Are, in fact, both of these proposed?
-- 
-------------
Brett Galloway
{pesnta,twg,ios,qubix,turtlevax,tymix,vecpyr,certes,isi}!wjvax!brett