gwyn@BRL.ARPA (VLD/VMB) (01/17/86)
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.
terryl@tekcrl.UUCP () (01/19/86)
> 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.
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (01/22/86)
> > 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.
davet%tp4@rand-unix.arpa (Dave Truesdell) (01/23/86)
> From: terryl%tekcrl.uucp@BRL.ARPA > Date: 18 Jan 86 22:42:40 GMT > > > 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. > > 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. Sun's NFS seems to handle this sanely. Perhaps the solution is to keep the semantics of the filesystem the same. (i.e. a tree, and not a cyclic graph.) The system manager would have the responsability of keeping the remote mounts from causing a loop. (A commercial system would have to make sure of this, by enforcing some constraints.) Symbolic links are, as always, a special case. I agree with Doug Gwyn, the "remoteness" of the remote filesystems should be transparent.