Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!bellcore!faline!ulysses!hector!ekrell
From: ekrell@hector.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: Symbolic Links
Message-ID: <2972@ulysses.homer.nj.att.com>
Date: Thu, 17-Sep-87 20:05:30 EDT
Article-I.D.: ulysses.2972
Posted: Thu Sep 17 20:05:30 1987
Date-Received: Sat, 19-Sep-87 16:17:13 EDT
References: <2931@ulysses.homer.nj.att.com> <1817@munnari.oz> <2934@ulysses.homer.nj.att.com> <1014@wjvax.wjvax.UUCP>
Sender: daemon@ulysses.homer.nj.att.com
Reply-To: ekrell@hector (Eduardo Krell)
Organization: AT&T Bell Labs, Murray Hill
Lines: 39

In article <1014@wjvax.wjvax.UUCP> brett@wjvax.UUCP (Brett Galloway) writes:

>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?

Yes, but they're really the same thing.

The path state information has nothing to do with the "cd" command. There's
a notion of a "current working directory" in the kernel which is kept on a per-user
level in the u block. Each time a chdir() is done, this current working directory
is changed. This is what "cd" uses. The kernel also needs to know this current
working directory to resolve relative pathnames like "foo/bar/../file".
There's also a notion of a user's "root directory" which is needed because of
chroot(2) (the meaning of "/" is context sensitive).

The proposed change is handled within namei(), the kernel function which
resolves a file name like "/u/foo/bar/../file" into the actual place in the
disk where the file is (device, inode pair). namei() is used for both "cd"
(which uses chdir() which calls namei()), and opening or stating a file,
(which call name() internally).
    
    Eduardo Krell                   AT&T Bell Laboratories, Murray Hill

    {ihnp4,seismo,ucbvax}!ulysses!ekrell