Subject: Re: Special file names "." and ".." in READDIR response

From: Brent <[email-masked]>
Date: Wed, 03 Nov 1999 09:57:39 -0800

Peter Staubach wrote:
> So, how does a client handle talking with a server which does support
> "." and ".." entries?  What does it do when it encounters a server
> which does not support these entries?  Does it now have to understand
> what sort of server that it is talking to?

If it's a UNIX server has  "." and ".." then the server must
not return these entries if they refer to the current and
parent directories, i.e. server edits them out.  If it's
a UNIX client that needs "." and ".." entries, then it
can put them back in.  That's what our prototypes do now.

The client really doesn't have to understand what kind of
server it's talking to.  If "." and ".." entries show up,
then the v4 client must naively accept them as bona fide
directory entries with no special meaning.

This could get a bit awkward if the client can't handle
the name.  For instance, a file on a non-UNIX server
called ".." would be inaccessible to a UNIX client.  Though
that gets into the topic of name formats, e.g. a directory
entry name with a slash in it would cause similar grief.

	Brent

---

From: Peter Staubach <[email-masked]>
Date: Wed, 3 Nov 1999 08:57:22 -0800 (PST)

> 
> > I would suggest that the protocol make a statement that the
> > server insert the "." and ".." entries at the beginning of
> > the READDIR response if they are not natively
> > supported and describe them as aliases as they were in NFSv3.
> 
> It's great that the protocol, thusfar, has avoided reserving
> special names.  I'd be disappointed if we give in so easily
> to returning "." and ".." to the readdir result on the pretext
> that the client might get confused if they're not there.
> 
> I like Neil's suggestion to reserve values.  Cookie 0 is already
> reserved.
> Why not also reserve cookies 1 and 2.  Then the server
> can construct valid cookies just by adding 2 to the cookie
> value.  I'm sure the server can manage with those two cookie values
> missing from its cookie space.
> 

Having a generic file access model which hides most of the server/client
differences is such a clean thing.  It sure would be nice to not have to
sacrifice this.

	Thanx...

		ps