Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!bellcore!faline!ulysses!hector!ekrell
From: ekrell@hector..UUCP (Eduardo Krell)
Newsgroups: comp.unix.wizards
Subject: Re: Symbolic Links
Message-ID: <2878@ulysses.homer.nj.att.com>
Date: Wed, 26-Aug-87 23:35:13 EDT
Article-I.D.: ulysses.2878
Posted: Wed Aug 26 23:35:13 1987
Date-Received: Sat, 29-Aug-87 06:04:50 EDT
References: <8731@brl-adm.ARPA> <2789@ulysses.homer.nj.att.com>
Sender: daemon@ulysses.homer.nj.att.com
Reply-To: ekrell@ulysses (Eduardo Krell)
Organization: AT&T Bell Labs, Murray Hill
Lines: 27

In article <480@mtxinu.UUCP> ed@mtxinu.UUCP (Ed Gould) writes:

>It doesn't fall apart anywhere on my system (4.3BSD + NFS) except that
>/ is a special case: /.. == /

Imagine the following: you replace "cd" by a function that reads the directory
entries (including . and ..) directly and does its own version of chdir().
Call that program "ncd". Now, go to a mount point, say /foo/bar, and do "ncd ..".
The million dollar question: where are you now?

>Simple, perhaps, but no more so than the current BSD symlinks.  What's
>cleaner about it?

it's cleaner because I am guaranteed that if I "cd /usr/include/sys", then
any references to ".." like in "cd .." or "ls .." will refer to /usr/include
no matter what.

>Unless the kernel implements carrying an arbitrarily-long string with
>each process, then I claim that the implementation is broken.  Consider
>the following program, with DEPTH suitably large:

You forget that there's a hard-coded maximum pathname length in the kernel,
so I won't be breaking anything that's not broken already.
    
    Eduardo Krell                   AT&T Bell Laboratories, Murray Hill

    {ihnp4,seismo,ucbvax}!ulysses!ekrell