To . or not to .
l...@tut.uucp
amusing. Just in case some of you are serious, here is a
good example of another use of it.
for p in $x/*/.
do
stuff
done
p will only take on values of executable directories (with /.
appended). This is easier than the alternative of letting p
range over all of $x/* and then testing if it is the name of
an executable directory. Also, sometimes $x/* will expand
to too many characters and the script could fail. There are
other uses of . than meaning the current directory.
Larry Cipriani tut!lvc
Thomas Truscott
for far too long. They are cute, yes, but so was Gizmo.
We all know what "." and ".." mean, and so does UNIX.
Making them directory entries gives us a crutch,
but also hobbles us and blurs our view of the one true pathname.
They are a blot on all directory traversal programs.
They mock our beloved dot-files, bringing grief to those who do ".*".
They litter the file system, out numbering the directories themselves!
And riddle me this: why does an empty directory have two entries?
There is, quite simply, no good reason for
them to darken our directories. Consider yon shell script:
> for p in $x/*/.
> do
> stuff
> done
Is not $x/*/ shorter of breath yet fully as noble of purpose?
But supposing we wish to permit this folly,
could not the mighty shell, defender of SIGSEGV,
deign to look for "." and ".." as even now it looks for "/"?
Is this so great a price, when the humble
chmod chown cp csh diff du
ls rcp rm tar find uusnap
must all stand watch for the mocking entries,
lest they be locked within those lurking links?
What is the cost? A mere trifle.
The odd pathname matcher will need enlightment,
as must the handful of programs who foolishly skip
the first two directory entries.
What is the gain? Enlightenment itself,
for a heavy burden will indeed lift.
Morn not for "." and ".." for as they cast off
their wordly trappings they will be reborn,
fresh in meaning and pure in concept.
Tom Truscott
fr...@wacsvax.uucp
>All this discussion of getting rid of . and .. is pretty amusing. Just in case
>some of you are serious, here is a good example of another use of it.
> for p in $x/*/.
> do
> stuff
> done
>p will only take on values of executable directories (with /.
>appended). This is easier than the alternative of letting p
>range over all of $x/* and then testing if it is the name of
>an executable directory.
Please flame me if I am wrong but why wouldn't :
for p in $x/*/
do
stuff
done
be sufficient. I don't believe the . is necessary. However, don't
take this an argument for doing away with . and ..!
Frank O'Connor
Computer Science
University of Western Australia
Chris Torek
>Please flame me if I am wrong but why wouldn't :
> for p in $x/*/
> do
> stuff
> done
Well, for one thing, this uses the zero-length-string file name
(right there after the second slash: it refers to the current
directory as of that slash).
If System V's namei is consistent, this will fail in the same way
as open("", 0) (and it will not accept names like a//b or //x).
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690)
Domain: ch...@mimsy.umd.edu Path: uunet!mimsy!chris
The Beach Bum
Sorry to do this to you Chris, but that works just fine here.
I don't have sys/nami.c (or whatever the new name is) in front of me,
but my understanding of what is going on is this:
namei (func, mode)
char (*func) ();
int mode;
{
int c;
c = (func) ();
/* test for c == 0 to set u.u_error = ENOENT, or make current
inode == root inode or current directory inode. */
do
if room left insert character in u-page dirent structure.
while ((c = (func) ()) != '/' && c != 0)
while ((c = (func) ()) == '/' && c != 0)
toss character out because it was just a /.
/* at this point, c is '\0' or first char in next path name. */
/* go look in current directory for an entry that matches. */
/* if c == 0, return the current i-node, else go back. */
}
Okay. Did anyone not know this already? Now, my understanding of the
original bug was if the first `c' was '\0', the current I-node, which
was the current directory, since c != '/'. That's why "" == . in the
old world. Consider "/", where the first character returned is '/',
and after that, the next is '\0'. The test, if I understand, and unless
you have the sources, (which I don't, so I don't know ...), only happens
that one time. A much better test is if u.u_dent.d_name[0] == 0, and
return ENOENT. But '/' is still quite special ...
- John.
--
John F. Haugh II HECI Exploration Co. Inc.
UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600
"Don't Have an Oil Well?" Dallas, TX. 75243
" ... Then Buy One!" (214) 231-0993
Chris Torek
zero-length string as a name component, and that SysV should
therefore reject them. Those of you who are tired of this debate
should stop reading this article now.]
In article <19...@killer.UUCP> j...@killer.UUCP (The Beach Bum) writes:
>Sorry to do this to you Chris, but that works just fine here.
Actually, I had understood that to be the case. I was in fact
cloaking a philosophical argument for "" => current directory.
[implementation deleted]
>... my understanding of the original bug was if the first `c' was
>'\0', the current I-node, which was the current directory, since
>c != '/'. That's why "" == . in the old world. Consider "/", where
>the first character returned is '/', and after that, the next is '\0'.
Yes, consider it well!
>But '/' is still quite special ...
And (philosophically speaking) I consider this a fault. The fewer
special cases imbedded in a naming system, the better; *no* special
cases is ideal. If you wish to have both relative and absolute
naming, however, you must either provide two different name lookup
routines (in which case a name is no longer simply a string, but
rather a string and a selector) or add a special case. Unix uses
the special case, and ultimately I must agree with this particular
choice.
Now given the special case that a leading separator `/' indicates
an absolute path name, the proper (I claim) way to regard the name
lookup is this: First peek at the first character. If it is `/',
consume it, and begin at the root; otherwise begin at the current
directory. From then on every `/' is always a separator. Traverse
the file system by looking up every name component (including null
components such as the one in a//b) and stop only when you run out
of components or cannot find a component in the current directory
as of the most recent separator.
As it happens, the null name is not in fact stored in any directory.
But this is an *implementation detail*: it is entirely unrelated
to the apparent operation of the naming system. Like `.', the null
name refers to the current directory as of the most recent separator.
If you want to disallow null names, to be consistent you should (I
claim) disallow them everywhere: If open("") returns ENOENT, it
should do so only because the null name is not stored in the current
directory. But since the null name is not stored in the root
directory, open("/") should also return ENOENT. open("a//b") and
open("x/") should likewise fail.
*To be consistent, the null name must be nowhere or the null name
must be everywhere.* Since most people agree that `/' suffices to
name the root directory (`/.' being the next alternative), I say
that the null name is everywhere, and open("") should begin at the
current directory and find the null name and stop. System V's name
lookup routine claims that the null name is everywhere *except*
the current directory, and at that, only the first time it looks
there! (open("./" succeeds and opens the current directory.)
*This* is the behaviour to which I object.
Lawrence V. Cipriani
> Please flame me if I am wrong but why wouldn't :
> for p in $x/*/
> do
> stuff
> done
> be sufficient. I don't believe the . is necessary. However, don't
> take this an argument for doing away with . and ..!
>
> Frank O'Connor
Actually the problem seems to be in the shell and not the os. In
the Bourne shell on my SVR2 AT&T 3B5 */ expands to literall */
However, in the Korn shell on the same machine */ expands to
f1/ f2/ ... fn/
Where f1 f2 ... fn are the names of *files and directories* in .
Using csh under BSD */ expands to only directory names (at least
on the Pyramid machine I'm writing this on).
I wrote this short C program:
#include <sys/types.h>
#include <sys/stat.h>
main(argc, argv)
int argc; char *argv[];
{
register int i;
struct stat stbuf;
for (i = 1; i < argc; i++)
if (stat(argv[i], &stbuf) == -1)
printf("cannot stat '%s'\n", argv[i]);
}
Under BOTH BSD and SVR2 I ran it with arguments of
filename/ or directoryname/ the stat succeeded.
So it seems the os doesn't give a toot if there is
an extra slash or not. Same result if you use open
instead of stat (of course).
Now whether or not the shell should expand */ to include only
directories I don't know. It might would be useful. I can
mention this to Dave Korn as a suggestion for ksh if you want.
Larry Cipriani tut!lvc
Lawrence V. Cipriani
> If System V's namei is consistent, this will fail in the same way
> as open("", 0) (and it will not accept names like a//b or //x).
SVR2 (and any AT&T Unix system I'm familiar with) lets you use
multiple /.
//a is the same as /a
a//b is the same as a/b
This nice thing about doing it this way is that you can be a little
sloppy in your program and it will still work. I admit it I'm lazy!
And what is the harm anyway? Perhaps in some situations a // indicates
a broken program.
Another case of damned if you do and damned if you don't.
Larry Cipriani tut!lvc
John Chambers
> [Background: I claimed that */, a//b, and //x all have the
> zero-length string as a name component, and that SysV should
> therefore reject them. Those of you who are tired of this debate
> should stop reading this article now.]
>
with a new login id on a BSD machine which I needed to initialize to all the
stuff that I'm used to using. Being lazy, I just copied stuff from my main
host:
rcp -r foo: .
This worked just fine. Then it occurred to me that I had used the dreaded
null file name. The "foo:" string is of course parsable into the host name
"foo", a separator ':', and a directory name "". Since rcp prepends your
home directory to anything not starting with '/', it acts just like you'd
expect.
I'm glad it did this sensibly, and didn't tell me that "" is an illegal
pathname. There are too few hours in the day to waste them hassling with
silly software that won't do such straightforward, unambiguous commands
as the above because of someone's idea that null strings shouldn't exist.
--
John Chambers <{adelie,ima,maynard,mit-eddie}!minya!{jc,root}> (617/484-6393)
Snoopy
>SVR2 (and any AT&T Unix system I'm familiar with) lets you use
>multiple /.
>
> //a is the same as /a
> a//b is the same as a/b
>
>This nice thing about doing it this way is that you can be a little
>sloppy in your program and it will still work. I admit it I'm lazy!
>And what is the harm anyway?
The harm is that this is not portable. With UTek's DFS, //a refers to the
root directory on a machine called 'a'. I've seen articles indicating
that Apollo's multi-machine file system (whatever they call their version)
uses the same syntax. (Is anyone familiar with Apollo out there?)
Sloppy programming is not a good idea.
Snoopy
tektronix!doghouse.gwd!snoopy
sno...@doghouse.gwd.tek.com
Richard England
//a on an Apollo Domain network specifies a node name. Hence //a is
a no-no. Both BSD and SYSTEM V Unix on a Domain network will recognize
the node name so beware. Why not just stick to the published norms and
be safe?
--
----------------------------------------------------------------------------
Rich England | "...Cock o' the North? Ach! Yon's a cheesey
reng...@mntgfx.MENTOR.COM |tune. Weel no be playin' thaat tune!"
...!tektronix!sequent!mntgfx | Alec Guiness, "Tunes of Glory"
David Elliott
It's even more unportable, since the Apollo semantics differ when there
are more than two slashes.
That is //a means the root on machine 'a'. ///a means the same on the
Apollo, but with DFS it means the same thing as /a. This allowed us
to quickly fix sloppy code by changing sprintf's that use things like
sprintf(path, "%s/%s", ...)
to use //, though I think we tried to fix them all the right way.
In addition, we changed the home of users like root to be "/.", so
that programs that use "$HOME/path" wouldn't produce "//path" for
root.
I have mixed feelings about all of this, but I do hope that the V8
style (/n/host/...) will win out.
--
David Elliott d...@mips.com or {ames,decwrl,prls}!mips!dce
Lawrence V. Cipriani
More on //a and a//b so n now if you are tired of this discussion.
In article <93...@tekecs.TEK.COM>, sno...@doghouse.gwd.tek.com
(Snoopy) writes:
* In article <9...@tut.cis.ohio-state.edu> l...@tut.cis.ohio-state.edu
(Lawrence V. Cipriani) writes:
**SVR2 (and any AT&T Unix system I'm familiar with) lets you use
**multiple /.
**
** //a is the same as /a
** a//b is the same as a/b
**
**This nice thing about doing it this way is that you can be a little
**sloppy in your program and it will still work. I admit it I'm lazy!
**And what is the harm anyway?
Please quote everything that is relevant to your reply, thanks.
I also said that it might indicate you have a *broken* program.
Broken also means non-portable (to me). I take a great deal of
pride in my long lived programs and try to keep them as "clean"
as possible.
*Sloppy programming is not a good idea.
Of course, but neither is going to great lengths to make a program
"clean" that you are going to throw away in 10 minutes after your done
writing it.
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 ? Geez.
Stupid programming is worse than sloppy programming.
Larry Cipriani
...!cbosgd!cbsck!lvc AT&T Network Systems
...!cbosgd!osu-cis!tut!lvc Ohio State University
Unix is a registered trademark of AT&T Bell Laboratories.
AT&T is a registered trademark of American Telephone and Telegraph.
'da Kingfish
In article <9...@quacky.UUCP> d...@quacky.UUCP (David Elliott) writes:
>I have mixed feelings about all of this, but I do hope that the V8
>style (/n/host/...) will win out.
(and someone else later opined that // for a root was a bad idea)
we have apollos here, and they have // meaning the network root. for
/n/host style names, we just mkdir /n, and create links in there, so
that /n/fleetwood -> //fleetwood. that seems to work, althought i just
did it quickly to see.
myself, i like apollo and // because there are no mount points, or
mounts to worry about.
--paul
--
Trying everything that whiskey cures in Ann Arbor, Michigan.
Over one billion messages read.
and...@frip.uucp
"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....@relay.cs.net) [ARPA]
l...@tut.uucp
(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
Barry Margolin
> 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.
bar...@think.com
seismo!think!barmar
j...@killer.uucp
> In article <9...@quacky.UUCP> d...@quacky.UUCP (David Elliott) writes:
> >I have mixed feelings about all of this, but I do hope that the V8
> >style (/n/host/...) will win out.
>
> (and someone else later opined that // for a root was a bad idea)
>
Urph - I copy the Same Old .cshrc file from one system to another. Last
night I noticed that the /.cshrc file (for root) had the line
set path=(/bin /usr/bin /etc /usr/local/bin /usr/games $home/bin)
Which is the path I've used for several years. What's going to happen to
when I finally have the (mis)fortune to work on one of these network
machines?
- John.
--
John F. Haugh II SNAIL: HECI Exploration Co. Inc.
UUCP: ...!ihnp4!killer!jfh 11910 Greenville Ave, Suite 600
...!ihnp4!killer!rpp386!jfh Dallas, TX. 75243
"Don't Have an Oil Well? Then Buy One!" (214) 231-0993
David Elliott
[discussion of network filesystem path preferences deleted]
>
>Urph - I copy the Same Old .cshrc file from one system to another. Last
>night I noticed that the /.cshrc file (for root) had the line
>
>set path=(/bin /usr/bin /etc /usr/local/bin /usr/games $home/bin)
>
>Which is the path I've used for several years. What's going to happen to
>when I finally have the (mis)fortune to work on one of these network
>machines?
If the system administrator on the system has any kind of talent at
all, you won't have to do a single thing! In other words, if it's
misfortunate, it's application, not service, at fault.
I use the same .cshrc and .login that I used before we had NFS or /n
here, and I can continue to do so.
As an example, we only have one copy of /usr/games on our Mips M-series
BSD machines (on the host quacky), and everyone else has a symbolic link to
/n/quacky/usr/games. When I rlogin to another machine and execute, for
example, fortune, I get it. I don't have to change my path to include
/n/quacky/usr/games.
The biggest problems with network filesystems are not generally found
at the user's level, they are in administration.
Timothy R. Giebelhaus
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!giebe...@umn-cs.arpa
Nobody I know admits to sharing my opinions. I don't even have a pet.
Doug Gwyn
>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 Torek
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'.
Brent Callaghan
> 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
John Myers
University Computer Science Department's syntax:
/../host
"/.." is known as the "super-root". It seems logically consistent to me...
_.John
ka...@tut.uucp
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.
--
Karl
Doug Gwyn
>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 Klossner
"(and someone else later opined that // for a root was
a bad idea)"
"Urph - I copy the Same Old .cshrc file from one system to
another. Last night I noticed that the /.cshrc file (for root)
had the line
"set path=(/bin /usr/bin /etc /usr/local/bin /usr/games $home/bin)
"Which is the path I've used for several years. What's going
to happen to when I finally have the (mis)fortune to work on
one of these network machines?"
If it's one of our systems, /etc/passwd will say that root's home
directory is "/." not "/", and everything will work just fine.
Andrew Klossner
"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.)
giebe...@hi-csc.uucp
> 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.
Chris Torek
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 <94...@tekecs.TEK.COM> and...@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.
Ke Kupua
) Incidentally, I think the Internet growth has shown why flat name
) spaces are bad.
grep -i gwyn //edu//berkeley//monet/etc/passwd
??
chuckle, snort.
Matt
Brandon Allbery
+---------------
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!all...@harvard.harvard.edu
{hoptoad,harvard!necntc,cbosgd,sun!mandrill!hal,uunet!hnsurg3}!ncoast!allbery
Moderator of comp.sources.misc
David Brownbridge
>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"]
dun...@vuwcomp.uucp
>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.)
How do Sun make this work? If a locking daemon is running on a machine
that crashes then that daemon loses track of what files are locked.
If a client crashes, how does the locking daemon know to unlock files
that it had locked?
As Doug says, with the locking done by external daemons, the NFS protocol
itself remains stateless, but I can't see how you still don't lose the
benifits of it's statelessness.
Duncan
"The America's Cup -- why wait until 1991...?"
Domain: dun...@comp.vuw.ac.nz Path: ...!uunet!vuwcomp!duncan
Robert Stroud
/.. 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....@nss.cs.ucl.ac.uk
UUCP ...!ukc!cheviot!robert
JANET rob...@newcastle.cheviot
Ed Gould
>In article <67...@brl-smoke.ARPA> gw...@brl.arpa (Doug Gwyn) writes:
>>Fundamentally, NFS remains stateless. Last I heard, the locking was
>>being done by arrangement with external daemons.
>
>that crashes then that daemon loses track of what files are locked.
>If a client crashes, how does the locking daemon know to unlock files
>that it had locked?
There are actually two cooperating daemons: the lock manager and the
status monitor. They both exist on all machines. The status monitor
is responsible for notifying the lock manager of client crashes.
There is also a recovery protocol that allows clients to regain
locks if the server crashes. Before the rebooted server accepts
general lock requests, it accepts lock renewal requests for
a period of time.
--
Ed Gould mt Xinu, 2560 Ninth St., Berkeley, CA 94710 USA
{ucbvax,uunet}!mtxinu!ed +1 415 644 0146
"`She's smart, for a woman, wonder how she got that way'..."
Snoopy
|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 <94...@tekecs.TEK.COM> and...@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
sno...@doghouse.gwd.tek.com
Pizza. Just say yes!
Andrew Klossner
"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.
Rick Rashid
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.
Doug Gwyn
> % 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.
Snoopy
> % 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
sno...@doghouse.gwd.tek.com
"Here we come, a waddling..."
Thomas P. Mitchell
>In article <35...@sun.uucp>, brent%te...@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
>>
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 (mi...@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.