Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watmath!clyde!rutgers!mtune!codas!akgua!emory!arnold From: arnold@emory.UUCP Newsgroups: comp.unix.wizards Subject: Re: symbolic links are a botch Message-ID: <2075@emory.UUCP> Date: Sun, 7-Jun-87 13:20:52 EDT Article-I.D.: emory.2075 Posted: Sun Jun 7 13:20:52 1987 Date-Received: Thu, 11-Jun-87 02:03:00 EDT References: <2629@ulysses.homer.nj.att.com> <5962@brl-smoke.ARPA> Reply-To: arnold@emory.UUCP (Arnold D. Robbins {EUCC}) Organization: Math & Computer Science, Emory University, Atlanta Lines: 43 Keywords: file system, file name resolution In article <5962@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) writes: >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. This can actually be a run time decision instead of compile time; the shell diffs I posted two years ago from "gatech" did it that way. >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. The kernel need only keep track of the next to last component of the pathname used to get into the current directory, not the whole path name. This would allow ".." to work, although it could admittedly cause /bin/pwd to give suprising results in some cases. In fact, I don't see how the kernel's keeping the full path would help with /bin/pwd. >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). Amen. To change the subject slightly; it has always struck me as wierd that the mode bits on a symbolic link have absolutely no relevance to anything; if a symlink is created with mode 000, you can still do a readlink on it! The problem is, I can't come up with decent semantics for the mode bits. (I.E. I think the current semantics are wrong, but I can't come up with anything better.) How does the Ninth Edition handle it? Comments, anyone? -- Arnold Robbins CSNET: arnold@emory BITNET: arnold@emoryu1 ARPA: arnold%emory.csnet@csnet-relay.arpa UUCP: { akgua, decvax, gatech, sb1, sb6, sunatl }!emory!arnold