Subject: Re: READDIR cleanup

From: Peter Staubach <[email-masked]>
Date: Tue, 2 Nov 1999 16:54:53 -0800 (PST)

> 
> > > From NFSv3 we have lost the cookieverifier as part of the request
> > > and response.  So the server doesn't have a method to confirm
> > > the cookie.  Is that okay?  I would think not.
> > >
> > 
> > From my viewpoint, the cookieverifier was a failed experiment in NFS
> > Version 3.  The semantics were never well understood nor supported by
> > many local file systems.  The Solaris NFS server always returns zeros
> > in the cookieverifier field.
> 
> The server will rely on its internal tracking of cookies it provides
> to determine if it should return NFS4ERR_BAD_COOKIE for a particular
> use of a cookie value by a client.  The client will then need to 
> deal with the BAD_COOKIE error.  I will need to add a description of what
> the client is supposed to do with a BAD_COOKIE error.
> 

I will raise a question/poll in response.  Does anyone have a client
which can actually do anything valid with an NFS4ERR_BAD_COOKIE or
even an NFS3ERR_BAD_COOKIE?  It is not the sort of error that can be
handled by the client NFS implementation.  It needs to get returned
back to the application level in order for it to determine what
should be done.  There aren't any UNIX systems that I am aware that
can correctly a "bad cookie" error, are there any other operating
systems which can?

	Thanx...

		ps

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 02 Nov 1999 19:14:03 -0600

> can correctly a "bad cookie" error, are there any other operating

How does the server communicate the stale or bad cookie to the client?
It needs some sort of error return.  I agree that it is difficult
for the Unix client to deal with such an error but what is the
server supposed to do with a bad cookie value other than return an
error.

Spencer