Subject: RE: [nfsv4] rdattr_error for non-READDIR ops?

From: "Noveck, Dave" <[email-masked]>
Date: Tue, 30 May 2006 15:31:56 -0400

For VERIFY and NVERIFY, the spec is pretty explicit:

   When the attribute rdattr_error or any write-only attribute (e.g.,
   time_modify_set) is specified, the error NFS4ERR_INVAL is returned to
   the client.

For CREATE, the spec says, 

   The createattrs specifies the initial set of attributes for the
   object.  The set of attributes may include any writable attribute
   valid for the object type. 

which to me seems to imply that anything outside that set nor valid,
making INVAL seem like the right choice.

For GETATTR, the spec strongly implies that simply not returning either
data or the error is not valid:

   The server must return a value for each attribute that the client
   requests if the attribute is supported by the server.  If the server
   does not support an attribute or cannot approximate a useful value
   then it must not return the attribute value and must not set the
   attribute bit in the result bitmap.  The server must return an error
   if it supports an attribute but cannot obtain its value.  In that
   case no attribute values will be returned.

   All servers must support the mandatory attributes as specified in the
   section "File Attributes".

Since rdattr_attr is a mandatory attribute, it sounds to me like the
server must return a value or an error.  Since rdattr_error is supported
NOTSUPP would seem wrong.  Although uou can quibble about just how 
"useful" it is, it seems that returning the value zero is clearly not
incorrect given this text since there cannot be any error for a GETATTR 
that doesn't get an error.

It seems to that attr-not-supported does not convery the appropriate
facts
to the client.  He made a (stupid) error and should be told something is
really wrong.  For v4.1, I would say INVAL or a new error ATTR_INAPP 
should be returned in all such cases (except where the inappropriateness
is due to the absence of a file system in which case MOVED is correct).

If we can reach consensus on this, I volunteer to the make the
appropriate
spec edits for v4.1, just as soon as Spencer posts the spec XML to the
v4.1 editor web site, as he has been threatening to do :-)

-----Original Message-----
From: Spencer Shepler [mailto:[email-masked]] 
Sent: Tuesday, May 30, 2006 3:05 PM
To: [email-masked]
Subject: Re: [nfsv4] rdattr_error for non-READDIR ops?

On Tue, J. Bruce Fields wrote:
> Is it reasonable to return INVAL when rdattr_error is requested on any
> operation other than READDIR?

For GETATTR, the server would just ignore that particular attribute
and continue with the rest.  For VERIFY, NVERIFY, OPEN, SETATTR, CREATE,
the server would return NFS4ERR_ATTRNOTSUPP

Spencer

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 30 May 2006 15:38:19 -0400

> is due to the absence of a file system in which case MOVED is correct).

I'd be in favor of just INVAL.

--b.