loverso@encore.UUCP (John LoVerso) (01/01/70)
In article <6769@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: > In article <411@PT.CS.CMU.EDU> jgm@K.GP.CS.CMU.EDU (John Myers) writes: > >CMU CS rfs syntax: > >/../host > > So, what is the result of > $ cd /.. > $ pwd It gives "/.."! This isn't as clean as it could have been (at least on the MACH system here). If I've gotten this correctly, /../.. is the "real" superroot, with bin, lib, etc, dev, and all the boot paraphernalia. /../../RFS (aka /..) is the RFS "mount" point for other hosts, as in "/../host". /../../RFS/.LOCALROOT is "/". /bin, /lib, /dev and /etc are all patched into /../.. using hard links, which can really be confusing: % cd /../.. % pwd /../.. % cd bin % pwd /bin And people complained about slinks. John
andrew@frip.UUCP (11/20/87)
[]
"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]lvc@tut.UUCP (11/22/87)
In article <9398@tekecs.TEK.COM>, andrew@frip.gwd.tek.com (Andrew Klossner) writes: 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. That is what I meant, though I would never give another system access to a non public file system intentionally. My main objection to //a is the null between the two / (this is one of those computing religous issues). Certainly there is a difference in what the path name means when the remote system is mounted or not, but I can live with it. 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), That is what I meant, and I agree that it wouldn't be practical for more than a dozen or so systems. I wouldn't use it for more than a few. I work in an environment (AT&T) with thousands of machines wired together with uucp (using DATAKIT VCS and phone lines). I'm pretty happy with the functionality, but the security needs to be better. Do you really need instant access to hundreds of machines? 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. Not necessarily, as long as the disks are working, and the network can talk to disks directly, you don't need the other systems running. I don't know much about networks, are there any that can do this? I had something like this with two PDP 11/70's that shared dual ported disks (not a great analogy but you get the idea). Thanks for your note. Larry Cipriani AT&T Network Systems at cbosgd!osu-cis!tut!lvc Ohio State University
barmar@think.COM (Barry Margolin) (11/23/87)
In article <9398@tekecs.TEK.COM> andrew@frip.gwd.tek.com (Andrew Klossner) writes: > 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. If you use a stateless protocol such as NFS the last problem (servers rebooting) goes away. Mounting them in the background partially alleviates the problem of there being too many; while you may still have to wait for a particular file system to be mounted before you can reference it, you don't have to wait for all of them before you can start using the machine. I don't know what you mean by "access permissions are fluid". --- Barry Margolin Thinking Machines Corp. barmar@think.com seismo!think!barmar
jh@pcsbst.UUCP (11/29/87)
I don't like the //a solution either. E.g. I have seen cpio producing names like //usr/.... We at PCS use mount point for our *transparent* network MUNIX/NET. These mount points are normally located within a superroot directory "/.." (which is not linked to "/"). Thus, /../remote/etc/passwd would give you the access to the password file on a remote site. For name transparency even /../local/etc/passwd is allowed. This is not a mount point but a link. We do not have difficulties with unexpected shutdowns or crashes of remotes sites, because once mounted, each site is remounted automatically if it comes up again. Johannes Heuft unido!pcsbst!jh
giebelhaus@hi-csc.UUCP (Timothy R. Giebelhaus) (11/29/87)
There seem to be two issues: 1) the place the mounts take place and 2)
the method and the functionality of the mount.
I like the // mount because it places my machine at the same level as
all the rest of the machines on the network. My machine is //lime which
while I am on my machine is also /. I could place my machine in with
the other mounts in /n/lime which would be a link to / on my machine,
but I'm too lazy to place links on all my machines. Not much of a difference,
though.
What I really like is the method and the functionality of the mount. I
put the name of the machine in the name server (ns) and then all machines
can access it. The mount seems to be dynamic and fast. I don't have to
put any mounts into the rc file. Again, I'm lazy... especially when I
can get the job done with less work using a different method.
I also don't believe in stateless protocols for file sharing. NFS seems
to be implementing file locking which I believe means it is no longer
a stateless protocol.
--
---------------------------------
UUCP: {uunet, ihnp4!umn-cs}!hi-csc!giebelhaus
ARPA: hi-csc!giebelhaus@umn-cs.arpa
Nobody I know admits to sharing my opinions. I don't even have a pet.gwyn@brl-smoke.ARPA (Doug Gwyn ) (11/29/87)
In article <38c15248.4580@hi-csc.UUCP> giebelhaus@hi-csc.UUCP (Timothy R. Giebelhaus) writes: >I like the // mount because it places my machine at the same level as >all the rest of the machines on the network. The main problem with the // scheme is that it is not sufficiently general. "grep -i gwyn /n/ucbvax/n/monet/etc/passwd" should work, but I doubt that "grep -i gwyn //ucbvax//monet/etc/passwd" would, given the already-existing rule about stripping out redundant embedded adjacent /s. One would have to change that rule also. >I put the name of the machine in the name server (ns) and then all machines >can access it. There is no reason that /n could not be a name-server file system. >NFS seems to be implementing file locking which I believe means it is no >longer a stateless protocol. Fundamentally, NFS remains stateless. Last I heard, the locking was being done by arrangement with external daemons. (It is actually record locking, in support of SVID requirements, not just whole-file locking.)
chris@mimsy.UUCP (Chris Torek) (11/29/87)
Not having to mount remote machines is certainly a convenience; and given that I have never had several thousand machines all cross-mounted, I will (for the sake of argument at least) take the word of the Apollo folks that it is virtually a necessity. Let us assume that this is so. Yet I still claim that `//host' is a bad syntax. Why? Because it adds yet another special case (doubling the number of special cases!), embedding still more semantics in filename strings themselves (as opposed to the files reached by the strings). I think that this is bad. If you must use a special string, consider instead `/n'. You can still have the kernel recognise this `by magic', but now it looks like an ordinary directory. As a `for instance', if // is to be consistent (or if /n is to be consistent), one should be able to say cd //; cd host or cd /n; cd host and get the same effect as cd //host or cd /n/host There are several possible implementations for /n (one being `special magic string', another being file system switches or virtual file systems). The telling point, though, is that /n/host/somewhere `looks like' an ordinary file name, and that if for some reason everyone decided that the name `/n' is wrong and that it should be `/vogon' instead, well, no problem: /vogon/host/somewhere It still looks just like an ordinary file name. There is (from an external viewpoint, at any rate) no magic attached to a special part of that file name. (Oh all right, not as *much* magic.) Whether you wish to implement `ls /n' is another matter entirely, but this seems somehow more reasonable if your network switch point is `just another directory'. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
brent%terra@Sun.COM (Brent Callaghan) (11/30/87)
In article <9559@mimsy.UUCP>, chris@mimsy.UUCP (Chris Torek) writes: > Whether you wish to implement `ls /n' is another matter entirely, > but this seems somehow more reasonable if your network switch point > is `just another directory'. Another good reason for "just another directory" is that it leaves open the possibility of having nodes other than host names under the directory. Consider the following: /host/<hostid> - file systems on other hosts /home/<userid> - users home directories /src/<version> - other source trees There's not always a need to know the host on which a file resides. There are good reasons for hiding this information e.g. because you don't know the disk partition a file is in the administrator can relocate disk partitions freely. Similarly a /home directory allows a user to move to another host and have his/her home directory mounted automatically. This scheme is perfectly feasible through the use of a user-level NFS server that can catch file references on the fly and do mounts transparently. The name to host:directory mapping can be established through the use of a local or globally accessible table. Made in New Zealand --> Brent Callaghan @ Sun Microsystems uucp: sun!bcallaghan phone: (415) 691 6188
jgm@K.GP.CS.CMU.EDU (John Myers) (11/30/87)
Just to add to the confusion, let me put in a plug in for the Carnegie-Mellon University Computer Science Department's syntax: /../host "/.." is known as the "super-root". It seems logically consistent to me... _.John
karl@tut.UUCP (12/01/87)
jgm@K.GP.CS.CMU.EDU writes:
Just to add to the confusion, let me put in a plug in for the
Carnegie-Mellon University Computer Science Department's syntax:
/../host
But this didn't originate with CMU, yes? The Newcastle Connection
was the first to implement it that way, I believe. Credit where
credit is due, and all that.
--
Karlgwyn@brl-smoke.ARPA (Doug Gwyn ) (12/01/87)
In article <411@PT.CS.CMU.EDU> jgm@K.GP.CS.CMU.EDU (John Myers) writes: >Just to add to the confusion, let me put in a plug in for the Carnegie-Mellon >University Computer Science Department's syntax: >/../host Stolen from the Newcastle Connection. >"/.." is known as the "super-root". It seems logically consistent to me... So, what is the result of $ cd /.. $ pwd
andrew@frip.gwd.tek.com (Andrew Klossner) (12/02/87)
[]
"The main problem with the // scheme is that it is not
sufficiently general.
"grep -i gwyn /n/ucbvax/n/monet/etc/passwd
"should work, but I doubt that
"grep -i gwyn //ucbvax//monet/etc/passwd
"would."
What you really want (at least in the environment I work in) is
grep -i gwyn //monet/etc/passwd
All hosts reside in the same flat name space, so going to a host
through another host isn't implemented. (Network gateways are
implemented with the usual TCP/IP routing mechanism, transparently to
the network file system.)
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]giebelhaus@hi-csc.UUCP (12/02/87)
In article <35000@sun.uucp>, brent%terra@Sun.COM (Brent Callaghan) writes: > Another good reason for "just another directory" is that it leaves > open the possibility of having nodes other than host names under > the directory. Consider the following: > > /host/<hostid> - file systems on other hosts > /home/<userid> - users home directories > /src/<version> - other source trees > > There's not always a need to know the host on which a file > resides. There are good reasons for hiding this information > e.g. because you don't know the disk partition a file is in > the administrator can relocate disk partitions freely. > Similarly a /home directory allows a user to move to another host > and have his/her home directory mounted automatically. But the // directory is just another directory. It is simply a directory above the / directory. The only things special about it is I cannot reference a remote // directory (I can only reference the / directory and below) and the // name its self. I can put links in or anything I want. I'm a bit confused about how the /home directory works. We have about 30 suns and I have been trying to figure out how to arrange the cross mounts and such. We have four servers and each server has at least one partition of user files. I can't figure out how to get the path to the home directory look the same for all people no matter what server they log in on and still make it so I can move them from server to server without them knowing. What I am doing now is making links from a /udd directory. All users have a link in the /udd directory to either //host/user/user-name on the apollo or /n/host-name/user-name. host-name is the name of the host, but it is the directory (partition) on that host with the user files in it. I have some steps so that the loss of the /udd dir is not so bad like putting the /n/host-name/user-name in the /etc/passwd file and keeping replicas of the /udd dir. I'm still not happy with this though. Is there a better way? P.S. About my previous message, I do know the lock protocol is seperate from nfs. I meant to say it was added for use with nfs, not a part of nfs which could not be seperated. I'll put more effort in remaining clear in the future. -- --------------------------------- UUCP: {uunet, ihnp4!umn-cs}!hi-csc!giebelhaus ARPA: hi-csc!giebelhaus@umn-cs.arpa Nobody I know admits to sharing my opinions. I don't even have a pet.
chris@mimsy.UUCP (Chris Torek) (12/02/87)
In another article whose referent has been deleted, Doug Gwyn gives the following example: >> grep -i gwyn /n/ucbvax/n/monet/etc/passwd >> should work, but I doubt that >> grep -i gwyn //ucbvax//monet/etc/passwd >> would. In article <9446@tekecs.TEK.COM> andrew@frip.gwd.tek.com (Andrew Klossner) writes: >What you really want (at least in the environment I work in) is > grep -i gwyn //monet/etc/passwd >All hosts reside in the same flat name space.... This one is too easy. There are places that, for administrative reasons (read `paranoia and/or pinheadedness' :-) ), *require* such indirection. (I am not claiming that UCB is one such.) Incidentally, I think the Internet growth has shown why flat name spaces are bad. -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris
matt@oddjob.UChicago.EDU (Ke Kupua) (12/02/87)
In article <9591@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes:
) Incidentally, I think the Internet growth has shown why flat name
) spaces are bad.
grep -i gwyn //edu//berkeley//monet/etc/passwd
??
chuckle, snort.
Mattallbery@ncoast.UUCP (Brandon Allbery) (12/03/87)
As quoted from <411@PT.CS.CMU.EDU> by jgm@K.GP.CS.CMU.EDU (John Myers): +--------------- | Just to add to the confusion, let me put in a plug in for the Carnegie-Mellon | University Computer Science Department's syntax: | | /../host | | "/.." is known as the "super-root". It seems logically consistent to me... +--------------- Altos WorkNet: @host/path. The machines on the network need not be mounted, just named as being on the network. Requests are passed off by the kernel to user-mode network servers. If you happen to want V8 syntax, "ln -s @ /n/" and then "/n/host/foo" will be handled properly (as @host/foo). All is not roses, however. Personally, I think both syntaxes are ugly, but it *does* work and it is flexible. (The @ syntax screws up programs like "emacs" which generate full pathnames, and the symlink solution doesn't change what pwd says. As for the symlink itself, it looks to me like an ugly special case construction (that trailing slash on the "/n/" is REQUIRED).) I rather suspect that network disks are as slippery as symlinks: There just isn't a solution. I *do* think the V8 syntax (/n/host) is nicest of the no-mount systems, but the mounted network disks are most flexible. (This may say more about changes needed to "mount" than about networked file systems, however. Anyone want to recap "generalized mounts"?) -- Brandon S. Allbery necntc!ncoast!allbery@harvard.harvard.edu {hoptoad,harvard!necntc,cbosgd,sun!mandrill!hal,uunet!hnsurg3}!ncoast!allbery Moderator of comp.sources.misc
drb@praxis.co.uk (David Brownbridge) (12/03/87)
In article <411@PT.CS.CMU.EDU> jgm@K.GP.CS.CMU.EDU (John Myers) writes: >Just to add to the confusion, let me put in a plug in for the Carnegie-Mellon >University Computer Science Department's syntax: > >/../host We built a system which also allowed super-super-roots and so on ad infinitum. /../NearbyHost /../../OtherSite/host /../../../OtherCountry/AnotherSite/host "/.." makes sense to me which is why I promoted it as the "University of Newcastle upon Tyne Computing Laboratory's syntax" :-) Some old-timers must remember the "Newcastle Connection" distributed UNIX system which Lindsay Marshall and I wrote in 1981-2. "Not for the iron fist but for the helping hand" [Billy Bragg/Oyster Band "Between The Wars"]
robert@cheviot.newcastle.ac.uk (Robert Stroud) (12/05/87)
In article <6769@brl-smoke.ARPA> gwyn@brl.arpa (Doug Gwyn (VLD/VMB) <gwyn>) writes: >In article <411@PT.CS.CMU.EDU> jgm@K.GP.CS.CMU.EDU (John Myers) writes: >>Just to add to the confusion, let me put in a plug in for the Carnegie-Mellon >>University Computer Science Department's syntax: >>/../host > >Stolen from the Newcastle Connection. > >>"/.." is known as the "super-root". It seems logically consistent to me... > >So, what is the result of > $ cd /.. > $ pwd /.. of course!! If you add directories above root (and remember that with the Newcastle Connection, /.. was just a directory rather than some mysterious "super-root") so that it is possible for your current directory to be in an uncle or cousin relationship with root (rather than a direct descendent), then you have to modify the pwd algorithm accordingly. pwd assumes that if you go up the tree with ".." enough times you will get to root. If your current directory is in a sideways relationship to root, this assumption will no longer be valid. The modified pwd algorithm should work like this: (1) Go up the tree with .. from your current directory until you find / or reach the base of the tree (a directory which is its own parent). (2) If you didn't reach / in (1), then starting from / go up to the base of the tree with .. and prefix the appropriate number of /..'s to the string from (1). For example, after cd /../../C/D, step (1) will give /C/D and step (2) will give /../.. so the answer is /../../C/D. This is relatively straightforward to implement. I've made the necessary modifications to the System V /bin/pwd and sh (which has a built-in pwd) for use with a kernel implementation of the Newcastle Connection. The tricky bit is getting the shortest possible pathname. For example, if / corresponds to /../../A/B in the global naming tree, then after cd /../C, the modified pwd algorithm would give /../../A/C which is correct but redundant. (/../../A is the same as /.. if / is /../../A/B). This can be fixed if you keep a record of everywhere you visit in (1) and stop in (2) when you reach somewhere you've visited before, but since in an infinite naming tree this would require an infinite amount of storage and isn't very efficient in any case, it is easier to simply implement the algorithm given (which also requires an infinite amount of storage in the general case of course!) and ignore this problem. Robert J Stroud, Computing Laboratory, University of Newcastle upon Tyne. ARPA robert%cheviot.newcastle@nss.cs.ucl.ac.uk UUCP ...!ukc!cheviot!robert JANET robert@newcastle.cheviot
snoopy@doghouse.gwd.tek.com (Snoopy) (12/12/87)
In article <9591@mimsy.UUCP> chris@mimsy.UUCP (Chris Torek) writes: |In another article whose referent has been deleted, Doug Gwyn gives |the following example: |>> grep -i gwyn /n/ucbvax/n/monet/etc/passwd |>> should work, but I doubt that |>> grep -i gwyn //ucbvax//monet/etc/passwd |>> would. |In article <9446@tekecs.TEK.COM> andrew@frip.gwd.tek.com (Andrew |Klossner) writes: |>What you really want (at least in the environment I work in) is |> grep -i gwyn //monet/etc/passwd |>All hosts reside in the same flat name space.... |This one is too easy. There are places that, for administrative |reasons (read `paranoia and/or pinheadedness' :-) ), *require* |such indirection. (I am not claiming that UCB is one such.) You will be happy to learn that //host1//host2/etc/passwd does in fact work under DFS. And you *can* mount remote filesystems if you really want to. I prefer using symbolic links which: (a) are more flexible, and (b) don't require the superuser(s) to get involved. (No, let's not start the symlink argument again!) Snoopy tektronix!doghouse.gwd!snoopy snoopy@doghouse.gwd.tek.com Pizza. Just say yes!
andrew@frip.gwd.tek.com (Andrew Klossner) (12/12/87)
[]
"You will be happy to learn that //host1//host2/etc/passwd does
in fact work under DFS."
But it wasn't meant to; it only works by accident.
And a triple reference fails:
% ls -ld //lemming//hammer//tekecs
ls : //lemming//hammer//tekecs : Too many levels of symbolic links
(There were no symlinks among these three roots.)
"And you *can* mount remote filesystems if you really want to."
No you can't:
% /etc/mount //lemming/dev/ds66a /l
mount : //lemming/dev/ds66a on /l : Reference is to remote file (sys74)
"I prefer using symbolic links which: (a) are more flexible,
and (b) don't require the superuser(s) to get involved."
A big lose of symlinks for this is that root can accidentally "rm" the
connection. You can't "rm" a mounted mountpoint.
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]rfr@TEMP.IUS.CS.CMU.EDU (Rick Rashid) (12/12/87)
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.
gwyn@brl-smoke.ARPA (Doug Gwyn ) (12/13/87)
In article <2312@encore.UUCP> loverso@encore.UUCP (John LoVerso) writes: > % cd /../.. > % pwd > /../.. > % cd bin > % pwd > /bin Someone explained to me how at least one of these systems works; in theirs, the kernel was keeping track and the first chdir("..") from the root actually followed the link (which was "rejigged" to get to a directory of network machine portals) but a subsequent and all following consecutive chdir("..")s would get to the root "/" of the original system. This made the usual "pwd" algorithms continue to report the "right" thing, but although useful it's obviously very warty.
andrew@frip.gwd.tek.com (Andrew Klossner) (12/16/87)
[]
"I don't like the //a solution either. E.g. I have seen cpio
producing names like //usr/.... We at PCS use mount point for
our *transparent* network MUNIX/NET. These mount points are
normally located within a superroot directory "/.." (which is
not linked to "/")."
This also breaks existing programs; a common way to see if a directory
is the root of some file system is to see if "dir/.." is the same as
"dir/."
-=- Andrew Klossner (decvax!tektronix!tekecs!andrew) [UUCP]
(andrew%tekecs.tek.com@relay.cs.net) [ARPA]snoopy@doghouse.gwd.tek.com (Snoopy) (12/25/87)
In article <9514@tekecs.TEK.COM> andrew@frip.gwd.tek.com (Andrew Klossner) writes: > % ls -ld //lemming//hammer//tekecs > ls : //lemming//hammer//tekecs : Too many levels of symbolic links >(There were no symlinks among these three roots.) Obviously someone should fix the error message. > "And you *can* mount remote filesystems if you really want to." >No you can't: > % /etc/mount //lemming/dev/ds66a /l > mount : //lemming/dev/ds66a on /l : Reference is to remote file (sys74) Well, it *used* to let you do this. Fortunately there is no need for it. Snoopy tektronix!doghouse.gwd!snoopy snoopy@doghouse.gwd.tek.com "Here we come, a waddling..."
mitch@stride1.UUCP (Thomas P. Mitchell) (01/21/88)
In article <38d18d4f.4580@hi-csc.UUCP> giebelhaus@hi-csc.UUCP (Timothy R. Giebelhaus) writes: >In article <35000@sun.uucp>, brent%terra@Sun.COM (Brent Callaghan) writes: >> Another good reason for "just another directory" is that it leaves >> open the possibility of having nodes other than host names under >> the directory. Consider the following: >> >> /host/<hostid> - file systems on other hosts >> /home/<userid> - users home directories >> /src/<version> - other source trees >> >But the // directory is just another directory. The use of "//" in a file name string bothers me. I just had a case of gnu-emacs parsing a file name "/usr/me//.temp-filename" as "/.temp-filename". Not being superuser at the time I saw the error message. Searching found that my environment variable "$HOME" was being set to "/usr/mitch/". Changing the environment "$HOME" to "/usr/mitch" made the problem go away. I did not see the problem sooner because many utilities reduce "//" to "/" (try ls //). Emacs saw the double "/" and assumes that the user is over-riding a default and goes with the new file name. Well thanks for the soap. Thomas P. Mitchell (mitch@stride1.Stride.COM) Phone: (702) 322-6868 TWX: 910-395-6073 MicroSage Computer Systems Inc. a Division of Stride Micro. Opinions expressed are probably mine.