Subject: Re: ReadDir and file attrs

From: Brent Callaghan <[email-masked]>
Date: Thu, 14 Oct 1999 11:50:19 -0700 (PDT)

Sergey Klyushin wrote:
> There could be a problem if NFS Server can't fill all requested file
> attributes.
> 
> Protocol says that NFS Server should return error if it supports
> attribute, but can't get its value (for GETATTR).  What NFS Server
> should do in READDIR case?  Don't return file_name at all? - BAD Return
> error? - BAD.  NFS v.3 allows don't return any post_attributes in this
> case (READDIRPLUS), but with NFS v.4 Server should return error for
> READDIR.  My suggestion is don't return error, but return as much
> attributes as possible and for missing attributes NFS Client can use
> GETATTR later.  It means, that bitmap_mask will have different meaning
> for GETATTR and READDIR.  1 - means that attribute is present in
> attrlist_val, and 0 - means that attribute can't be retrieved this
> time, but not that it's not supported. NFS Client can always ask what
> attributes are supported with GETATTR request and supp_attr bit set.
> Probably the same meaning of bits in bitmap's "attrmask" is useful for
> GETATTR also.

The server MUST return the file name for each READDIR entry.
There is no option not to return the name.

Getting attributes in READDIR should be no different to
getting them in GETATTR.  I don't see why the behavior
should be different.  If the attributes don't come back
in READDIR then why should the client expect any better
luck with GETATTR ?

The spec requires the server return attribute bits set
to zero only for attributes that it doesn't support.
If the server supports the attribute, but can't return
it for some reason, then the client gets an error and
no attributes are returned.

You are suggesting that the server be allowed to indicate
a non-obtainable attribute with a zero attribute bit.
This would allow the client to get some attributes, rather
than none.  That seems reasonable to me, though it does
leave the problem of reporting the error to the client.
For instance, if the client asks just for an ACL and
gets back nothing, then it has no error to report. How
does it know whether the server had some kind of system
fault - or whether the ACL is unobtainable because of
a permission error ?

	Brent

---

From: "Sergey Klyushin" <[email-masked]>
Date: Thu, 14 Oct 1999 15:36:32 -0400

>fault - or whether the ACL is unobtainable because of
I agree with returning error and some attributes in GETATTR case,
but probably  you got me wrong with READDIR.
Let's say NFS Server successfully retrieved all requested attributes
for 100 files, but can't get only one of the requested attribute for
only one file. What NFS Server should return?
As I got from protocol, NFS Server should return an error and no file list.
My suggestion is
1. return NFS_OK status for READDIR, but not NFS4ERR_??
or return kind of NFS4ERR_ATTRIBUTE_IS_MISSING error AND the file list ALSO.
(Kind of "no post_attr")
2. return all file names and retrieved attributes
3. for that unlucky file - set bit to 0, which means - can't get it now,
but I do support it, if GETATTR set this bit to 1 in response to "supp_attr"
NFS Client can easy find out what attribute is missing and use
GETATTR for that file. There is a chance that GETATTR will succeed, and
there is a chance that not, but advantage is that NFS Client has the list
and
knows the error.

Sergey