Subject: ReadDir and file attrs

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

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.

Any comments?

---

From: Mike Eisler <[email-masked]>
Date: Thu, 14 Oct 1999 11:54:56 -0700 (PDT)

> Date: Thu, 14 Oct 1999 14:25:15 -0400
> From: "Sergey Klyushin" <[email-masked]>
> Subject: ReadDir and file attrs
> To: [email-masked]
> 
> 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

I agree that skipping the directory entry is unacceptable,

It seems to me the likelyhood of GETATTR returning error for a
supported attribute is low, so I don't think it is bad to return an
error for the entire READDIR. Perhaps I'm being myopic; are
there examples of attributes that periodically return errors?

> 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.

This takes us down the slippery slope of optional post-op attributes
which made NFS V3 client's complex. With the current attribute design,
if the client asks for an attribute, and doesn't get it, then he knows
he has to fake it for the application. Once you go to optional
post-op attributes, the client has to make additional RPCs to determine
what the situation is.

If we think that GETATTR failures are going to be common, then
we should re-visit the issue for GETATTR as well as READDIR.

	-mre