Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!ucsd!ucbvax!ulysses!hector!ekrell From: ekrell@hector.UUCP (Eduardo Krell) Newsgroups: comp.unix.wizards Subject: Re: Symbolic links and RFS Message-ID: <11573@ulysses.homer.nj.att.com> Date: 21 May 89 19:40:02 GMT References: <563@Aragorn.dde.uucp> <1662@auspex.auspex.com> <10300@smoke.BRL.MIL> <31533@bu-cs.BU.EDU> Sender: netnews@ulysses.homer.nj.att.com Reply-To: ekrell@hector.UUCP (Eduardo Krell) Organization: AT&T Bell Laboratories Lines: 26 In article <31533@bu-cs.BU.EDU> bzs@bu-cs.BU.EDU (Barry Shein) writes: >Symlinks generalized hard links by delaying the evaluation of the file >path until access time (although the effect seems more dramatic this >is basically what the difference is.) Well, it looks to me that the big difference is that symbolic links allow you to go outside your file system. You just can't do that with hard links. In an NFS/RFS environment, either way of interpreting symbolic links (by the client or the server) will break something. We need something more powerful. Apollo extended the symbolic links to include an environment variable in the link text. Then you can have symbolic links which look like "/$(HOST)/foo/bar" which will expand to whatever you $HOST variable is set. Locus had a way of making a symbolic link to point to the local root (ie, relative to the server) by having a special name like "/" being interpreted by the kernel to refer to the local root and not the client's root. There wasn't an actual "" entry in /, it's just a special name which the kernel knows about. Eduardo Krell AT&T Bell Laboratories, Murray Hill, NJ UUCP: {att,decvax,ucbvax}!ulysses!ekrell Internet: ekrell@ulysses.att.com