Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!cmcl2!brl-adm!brl-smoke!gwyn
From: gwyn@brl-smoke.UUCP
Newsgroups: comp.unix.wizards
Subject: Re: symbolic links are a botch
Message-ID: <5962@brl-smoke.ARPA>
Date: Fri, 5-Jun-87 03:15:35 EDT
Article-I.D.: brl-smok.5962
Posted: Fri Jun  5 03:15:35 1987
Date-Received: Sat, 6-Jun-87 07:16:35 EDT
References: <2629@ulysses.homer.nj.att.com>
Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 26
Keywords: file system, file name resolution

In article <2629@ulysses.homer.nj.att.com> dgk@ulysses.homer.nj.att.com (David Korn[eww]) writes:
>I recently added symbolic links to my version of System V Release 3
>kernel. I made sure that .. was always handled like an operator that
>moves you up one level.

The BRL SVR2 Bourne shell can be configured to handle symbolic links
either way insofar as "cd" and "pwd" go.  I always build it to act
the way the Korn shell does, so that "cd .." never drops me into a
surprising place.

To really address this problem fully satisfactorily, however, one
does need to make the kernel keep track of the path used to reach
the current working directory, as well as have ".." handled specially.

It is no longer guaranteed that one will get the "." and ".." entries
when reading a directory (using POSIX-compatible access routines), so
if you elect to not return a ".." entry in a directory you need not
even play the tricks with its inode number needed to make the revised
".." semantics work right.

I think you (David Korn) got it exactly right.  Symbolic links are
useful (thanks, Dennis!), but the deviation from strict hierarchical
directory structure was a major problem with them.  A system with
a sensible notion of current working directory such as you appear to
have would be best.  Please send the work to the Summit folks so we
can get good symlink support into SVRn (n > 3.1).