dgk@ulysses.UUCP (06/21/87)
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!dgkrbj@icst-cmr.arpa (Root Boy Jim) (06/23/87)
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%
The best way to do something wrong is to take a poll (especially if
it includes naive users) and implement the result.
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
Please explain. I hope that you are not using RFS's (possible) botches
to justify botching something else. BTW, NFS seems to work correctly.
b. The chroot(2) system call.
Again, please explain. The whole point of chroot is to nip the tree at
a given directory and create a virtual root. Enforcing the illusion
that `up' from `the root' is still `the root' is Doing The Right Thing.
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).
Good point. However, before you guys tackle something complex like
symbolic links, perhaps you had better finish the job on regular file
systems and implement `mkdir', `rmdir', and `rename' as system calls
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 shell can maintain any idea of `where you are' it likes.
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.
And a good thing too.
The Unix file system is complex enough. The least that we can do for
the name-space is "Save the Tree".
I am disappointed in you for not addressing any of my points in my
previous article, the one where I restated your objection as
`Disembodied working directories are a botch'.
David Korn
{ihnp4,allegra}!ulysses!dgk
(Root Boy) Jim Cottrell <rbj@icst-cmr.arpa>
National Bureau of Standards
Flamer's Hotline: (301) 975-5688gwyn@brl-smoke.ARPA (Doug Gwyn ) (06/23/87)
In article <7956@brl-adm.ARPA> rbj@icst-cmr.arpa (Root Boy Jim) writes: > About 50% of the respondents agreed with me completely. Another 30% >The best way to do something wrong is to take a poll (especially if >it includes naive users) and implement the result. The point of the poll was to garner sufficient "public" support to get the internal AT&T decision makers to seriously consider Korn's proposal. I'm sure Korn was not relying on the poll to help him determine the TECHNICAL viability of his proposal, but rather the POLITICAL viability. > 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 >Please explain. I hope that you are not using RFS's (possible) botches >to justify botching something else. BTW, NFS seems to work correctly. Cottrell, if you don't know what you're talking about then shut up. RFS is doing exactly the right thing in this case. BTW, NFS is hardly a model for "correct" semantics for UNIX file systems! >Good point. However, before you guys tackle something complex like >symbolic links, perhaps you had better finish the job on regular file >systems and implement `mkdir', `rmdir', and `rename' as system calls Mkdir & rmdir ARE system calls in the current version of UNIX. It is not especially advantageous to do this for ordinary file systems, but it certainly is for a distributed file system. Rename is more difficult and less urgent, but it too will probably move into the kernel soon. Your patronizing tone is totally inappropriate. I know several AT&T software developers (including Korn) who can run rings around you. Their biggest problem lies in the bureaucracy that lies between their prototypes and the official released product. To some degree this does make for higher quality (virtually every recent new feature in UNIX System V has had an improved design over the original prototype), but it does delay or even discourage the appearance of new features.