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.