Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!sunybcs!boulder!hao!husc6!mit-eddie!uw-beaver!tektronix!orca!tekecs!frip!andrew
From: andrew@frip.UUCP
Newsgroups: comp.unix.wizards
Subject: //host vs "mount point"
Message-ID: <9398@tekecs.TEK.COM>
Date: Fri, 20-Nov-87 11:51:32 EST
Article-I.D.: tekecs.9398
Posted: Fri Nov 20 11:51:32 1987
Date-Received: Sun, 22-Nov-87 13:22:03 EST
References: <648@tut.cis.ohio-state.edu> <1668@tut.cis.ohio-state.edu>
Sender: nobody@tekecs.TEK.COM
Organization: Tektronix, Wilsonville, Oregon
Lines: 27

[]

	"If you ask me, I think the //a syntax to indicate the root
	file system on machine a is brain dead.  Why not use a mount
	point instead of jerking around with //a ?"

If you mean syntactically recognizing
/mountRemotesHere/ucbvax/etc/passwd as a reference to
ucbvax:/etc/passwd, then it's just the same problem pushed down a ways;
the path already has an interpretation under standard Unix and laying a
new interpretation on top of it opens the way to ambiguity.

If you mean explicitly using a mount(8)-like command to bind an inode
to the remote root: this isn't practical in an environment of more than
a dozen or so systems.  I work in a network environment with literally
hundreds of systems (198 today on one Ethernet alone) where I refer to
foreign files as //othersystem/pathname.  If I had to mount (as root!)
each system before I could get to it, it would slow me way down.  But I
can't mount all these systems in /etc/rc; there are too many of them,
access permissions are fluid (just like working directories), and
Murphy's Law says the one I want will have rebooted since I last
mounted it so I'll have to remount it anyway.

One person's experience ...

  -=- Andrew Klossner   (decvax!tektronix!tekecs!andrew)       [UUCP]
                        (andrew%tekecs.tek.com@relay.cs.net)   [ARPA]