Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!ncar!hsdndev!spdcc!rbraun
From: rbraun@spdcc.COM (Rich Braun)
Newsgroups: comp.protocols.nfs
Subject: Re: Lookup of "." and ".."
Message-ID: <8130@spdcc.SPDCC.COM>
Date: 28 Jun 91 18:01:35 GMT
References: <1991Jun26.204047.28889@elroy.jpl.nasa.gov>
Organization: Kronos Inc., Waltham, Mass.
Lines: 34

david@elroy.jpl.nasa.gov (David Robinson) writes:
>A question for implementors of NFS clients.  How many would break if
>the NFS server stopped handling Lookup's of "." and ".."?
>...
>I do recall having to kludge in both "." and ".." for a non-Unix filesystem
>in order to make Unix clients happy.  In fact early connectathon testsuites
>seemed to imply that the server should return "." and ".." entries. Why
>force Unix files on the world when unneccesary?

I think the implementers of NFS originally tried to avoid this requirement
but didn't quite get it right; the parent file handle (inode) is handed
back to the client on every file lookup, so there *shouldn't* be a need
for "." and "..".  But these files were passed across in READDIR func-
tions, and I'll bet a lot of client implementations just took advantage of
this fact rather than acknowledging that "." and ".." are Unix-specific
constructs.

For the SOSS server, with which I'm most familiar, I solved the problem
of exporting a subdirectory of a filesystem by lying to the client about
the parent inode of that particular subdirectory.  For example, if I
export /c/foo, then I tell the client that "." and ".." both have the
inode number of directory C:\FOO.  But there's a catch:  if I export
two "filesystems", one of which is lower in the tree than the other
(example:  /c and /c/foo), then a user traversing from the higher-level
filesystem down into the lower-level one will become confused when he
tries to go back up (e.g., cd /c, then cd /c/foo/bar, then cd ../..
will go to directory /c/foo rather than /c).  Foo, I think I've just
confused a lot of netnews readers too!  ;-)

Anyway, I think this is the reason why Unix NFS implementations don't
let you export a subdirectory of a filesystem.  But there's nothing in
the protocol itself to prevent you from doing that, as SOSS demonstrates.

-rich