Path: utzoo!mnetor!uunet!husc6!cmcl2!rutgers!rochester!PT.CS.CMU.EDU!TEMP.IUS.CS.CMU.EDU!rfr From: rfr@TEMP.IUS.CS.CMU.EDU (Rick Rashid) Newsgroups: comp.unix.wizards Subject: Re: //host vs "mount point" Message-ID: <498@PT.CS.CMU.EDU> Date: 12 Dec 87 03:22:45 GMT References: <648@tut.cis.ohio-state.edu> <1668@tut.cis.ohio-state.edu> <2312@encore.UUCP> Sender: netnews@PT.CS.CMU.EDU Organization: Carnegie-Mellon University, CS/RI Lines: 62 Summary: More info on /.. The "/.." remote file system in use at CMU has a fair amount of history going back to 1980. It originated with a library based implementation called Lucifer done by Alex Schaeffer (now at Stanford). The idea, but not the code, was picked up on by Mike Accetta at CMU and implemented in an early BSD kernel in 1981. Originally, the syntax Mike used was "[host]/usr/foo". This caused no end of grief for UNIX programs which could not parse filenames with "[]" in them. Mike then picked up the "/.." idea from the Newcastle work. It was carried over into Mach by Mike and is one of two compatible remote file systems in use in CMU-CSD, the other being the ITC's VICE file system. A lot of fine tuning went into the use of "/.." and the way in which cd and pwd deal with remote directories. In particular, most things you say make sense if you think of /.. as the super-root directory which contains in it the root directories of machines on the network. For example: cd /../rfr/usr/rfr/../../../temp pwd Yields: /../.temp.ius.cmu.edu Where the pwd command provides the full domain name to disambiguate the machine for the user (a local convention). Also: cd /../rfr/usr/rfr/../../../temp/usr/rfr/../../../rfr/usr/rfr Is the same as: cd /../rfr/usr/rfr If you "cd /.." and say "ls" you get a list of all the machines in the CS Department. If you then "cd host" you are at the root for that host. The scheme is certainly not perfect. In particular, as noted in the previous notes, "/../.." must be thought of as special since it is, in fact, your "real root". While this makes some sense, and indeed /../../bin is really /bin, it can be confusing without an explanation (and even sometimes with one). Since "/../.." wouldn't logically mean anything but "super-super-root" I don't personally feel real bad about punning on it in this way, but I do understand the concern expressed. -Rick BTW: The use of "/../host" is a convention and not a requirement. In fact, the remote hosts links are special files which can be placed anywhere in your file hierarchy using a program called "remhost". Because /.. is so useful, this fact is seldom taken advantage of, however. One negative to the fact that the remote links are files is that you cannot simply access a host by /../host unless that host file has been entered. The cost of entering, though, is small and in practice hundreds of hosts are in our "/.." at CMU. It would be a relatively simple manner to add automatic updates to "/.." upon reference. There is already a daemon which will automatically switch symbolic links to remote directories from one machine to another upon host or network failure. This, combined with an automatic file replicator daemon, allows a (very) poor man's form of replicated remote files.