Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!think!harvard!seismo!brl-tgr!gwyn
From: gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>)
Newsgroups: net.unix-wizards
Subject: re: contributed RFS
Message-ID: <1830@brl-tgr.ARPA>
Date: Wed, 22-Jan-86 15:05:54 EST
Article-I.D.: brl-tgr.1830
Posted: Wed Jan 22 15:05:54 1986
Date-Received: Sun, 26-Jan-86 04:44:32 EST
References: <1697@brl-tgr.ARPA> <457@tekcrl.UUCP>
Organization: Ballistic Research Lab
Lines: 17

> > I applaud the contribution of RFS (which should be given some
> > other name to avoid confusion with AT&T's "RFS"), but I take
> > issue with the claim that one does not want "find / -print"
> > to cross over to remote file systems as it traverses the
> > directory.  To the contrary, that is the whole point of RFS
> > transparency.  There are some good examples (such as grepping
> > for "rnj" in /n/*/etc/passwd) in a Bell Labs paper published
> > one or two USENIXes ago.
> 
>      Ah, but probably not. Suppose two systems were linked by an RFS.
> Then, a "find / -print" would go into an infinite loop traversing both
> systems' file systems. Thus, you don't want find to cross over remote
> file systems. This (and similar) arguments are the same for symbolic
> links.

You could outlaw double-hops (probably easier than loop detection),
but RFS is pointless if you can't get even one hop.