Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!gatech!ulysses!dgk
From: dgk@ulysses.UUCP
Newsgroups: comp.unix.wizards
Subject: Followup - Symbolic links are a botch
Message-ID: <2669@ulysses.homer.nj.att.com>
Date: Sat, 20-Jun-87 18:44:49 EDT
Article-I.D.: ulysses.2669
Posted: Sat Jun 20 18:44:49 1987
Date-Received: Sun, 21-Jun-87 09:05:09 EDT
Organization: AT&T Bell Laboratories, Murray Hill
Lines: 69


This is a summary of the responses that I have received to my posting
of the article "Symbolic Links are a botch", to the USENET newsgroup
comp.unix.wizards.  The main point of the article was that .. should
always move you up one level (by name) towards the root even when you
use symbolic links.  This maintains the tree-like name space of the
UNIX file system.

About 50% of the respondents agreed with me completely.  Another 30%
agreed with me partially in one of the following three ways:
1.	They are a botch but they should be handled that way for the
	sake of compatibility.
2.	They are a botch but they should be handled like in BSD so that
	they are not transparent.  This will discourage their use except
	where absolutely necessary.
3.	They should be handled the way I describe by the shell but not
	by programs.

Another 20% felt that they should behave the way they do now in BSD because
1.	This will preserve compatibility.  If you change the behavior it
	will break software that relies on the BSD behavior.
2.	The directory of .. must be independent of the way you got there.
	Note that this has already been broken by
	a.	Remote mounts in RFS
	b.	The chroot(2) system call.
3.	That's what symbolic links are.

The primary concern about compatibility has to do with binding.  Some
have indicated that the relationship for .. is bound when the directory
is created and it never changes.  However, this is not true with BSD; it
changes when you move a directory.  (You can think of my implementation
of creating a symbolic link to a directory as moving a copy of the directory.
In fact, you can think of the linking a file or directory as making a replicated
copy of the file or directory; updating one copy updates all copies).

Currently, some programs rely on the following configuration:
	/official/src/cmd
		foo.c that include "../headers/file.h"
	/official/src/headers
		file.h
	/usr/whoever/src/cmd	->	/official/src/cmd
With the BSD implementation, a user <whoever> can change to their
sub-directory named src and run the command cc -c cmd/foo.c
and generate foo.o in their own src directory from the official
source.  The reason that this works is that the behavior of the include
"../headers/file.h" is not changed by the symbolic link /usr/whoever/src/cmd.

With my implementation you have to also add the symbolic link
/usr/whoever/src/headers	->	/official/src/headers
if you want the same behavior.  I think that this is a small price to
pay for preserving the tree-like name space of the file system.

One point made by users is that you will need another command to find
out where you 'really' are.  This, can be done of course, but we have
not found any need for it yet.  As far as I am concerned, you really are
where your path says you are.  You can check the device if you want
to find out what filesystem you are on.

The name space remains tree-like.  However, you can create symbolic links
that make the name space infinite (for example ln -s .. /foo creates an
infinite number of paths /foo, /foo/foo, /foo/foo/foo, etc.)  For this
reason the file tree walker (a subroutine used by our version of find)
guards agains infinite walks.

The Unix file system is complex enough.  The least that we can do for
the name-space is "Save the Tree".

David Korn
{ihnp4,allegra}!ulysses!dgk