RFS vs. NFS

Peter da Silva peter at ficc.ferranti.com
Thu Aug 23 07:11:24 AEST 1990


In article <1990Aug21.183615.8315 at ico.isc.com> rcd at ico.isc.com (Dick Dunn) writes:
> peter at ficc.ferranti.com (Peter da Silva) mentions:
> > For a third choice, Intel's OpenNET software...
> > ...Instead a super-root, "//", is created. To access
> > files on a remote system, you access "//sysname/usr/bin..."...

> Ugh!  This isn't the first time I've seen this trick, but it's still a bad
> idea.  I wish all the clever developers who decided, "Yeah, we can just use
> a double / for that!" had been experienced with UNIX before they inflicted
> their bright ideas on us.  Using // as magic *breaks* things.  Historically,
> extra /'s are ignored in file names.  People use this fact.

In practice, however, it breaks very few things. HDB UUCP is about the only
one I can think of, and people who let folks UUCP at random into their
entire network are just asking for trouble. More importantly, this has
become a common usage and is explicitly blessed by P1003.

I more or less agree that there are better choices: I like Futurenet's
"/../machine-name" super-root syntax. But in practice it works. You really
do need to use a name that can't be confused with an actual file name
if you want to avoid the remote-mount business, and "//" or "/../" certainly
serve that purpose. Either of them can confuse a sufficiently "smart"
program that "knows" that "//" and "/../" are really "root".

> To play in a subtree, you set ROOT=/usr/myhome/playpen or some such.  When
> you're ready to get serious, you set ROOT=/ which gives you FILE=
> //usr/bletch/gargle.

Which works just fine. OpenNET allows that unless you're sufficiently
daft to have a system on your network named "usr".

> (Don't bother telling me of the various ways to avoid the problem; I know.

There isn't a problem.

> Nor preach to me about standards; I'm talking about existing practice:-)

Me too.
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.   'U`
peter at ferranti.com



More information about the Comp.unix.i386 mailing list