Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!husc6!cmcl2!brl-adm!adm!rbj@icst-cmr.arpa From: rbj@icst-cmr.arpa (Root Boy Jim) Newsgroups: comp.unix.wizards Subject: Followup - Symbolic links are a botch Message-ID: <7956@brl-adm.ARPA> Date: Mon, 22-Jun-87 20:58:41 EDT Article-I.D.: brl-adm.7956 Posted: Mon Jun 22 20:58:41 1987 Date-Received: Tue, 23-Jun-87 07:25:50 EDT Sender: news@brl-adm.ARPA Lines: 82 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 National Bureau of Standards Flamer's Hotline: (301) 975-5688