Subject: readdir and eof

From: Jim Rees <[email-masked]>
Date: Thu, 08 Aug 2002 07:30:13 -0400

I know no one wants to extend the issues list at this point, but I would
just like to observe that I had a very hard time implementing readdir in my
client from the spec.  In particular, there is no discussion of what the eof
flag means.

Yesterday, for example, I came across a server that never sets the eof flag.
Instead it signals eof by returning no entries.  We decided that the server
was wrong in this case, but you wouldn't know that by reading the spec.

I suggest we lift the last setence from the rfc1094 readdir description and
make it the last sentence of our DESCRIPTION too:

     The "eof" flag has a value of TRUE if there are no more entries in the
     directory.

There is also a possible ambiguity in the spec.  Near the top of page 185 we
have

     For some file system environments, the directory entries "." and ".."
     have special meaning... they should not be returned to the client...

But then at the top of page 186 we have

     Since some servers will not be returning "." and ".." entries...

I suggest we change "should" to "must" in the first reference, and remove
the word "some" from the second.

One more thing.  What error does the server return if the cookie verifier is
no good?  Shouldn't this be specified so that the client has some hope of
recovering?

---

From: Spencer Shepler <[email-masked]>
Date: Thu, 8 Aug 2002 13:04:57 -0500

>      The "eof" flag has a value of TRUE if there are no more entries in the

This seems reasonable.

> the word "some" from the second.

The "should" has to stay in place for server's that support
regular/non-special meaning for filenames "." and ".." but it may not
be clear with current wording that this is the intent of the
statements you quote above.  I will review that and see if something
should be added

> no good?  Shouldn't this be specified so that the client has some hope of

Good catch.  One currently is not listed that would be of any help.  I
proposed that NFS4ERR_NOT_SAME be used if the READDIR verifier
mismatches.

-- 
Spencer