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

From: "J. Bruce Fields" <[email-masked]>
Date: Tue, 30 May 2006 13:50:36 -0400

Is it reasonable to return INVAL when rdattr_error is requested on any
operation other than READDIR?

--b.

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

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 30 May 2006 14:04:36 -0500

> 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

---

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

On Tue, May 30, 2006 at 02:04:36PM -0500, Spencer Shepler wrote:
> > Is it reasonable to return INVAL when rdattr_error is requested on
> > any operation other than READDIR?
> 
> and continue with the rest.  For VERIFY, NVERIFY, OPEN, SETATTR,
> CREATE, the server would return NFS4ERR_ATTRNOTSUPP

The server does actually support the attribute (it's mandatory, after
all); the reason we're objecting is that it doesn't make sense to use
that attribute with those operations.  So INVAL makes more sense,
doesn't it?  That's what the rfc actually requires for VERIFY/NVERIFY.

--b.

---

From: Spencer Shepler <[email-masked]>
Date: Tue, 30 May 2006 14:29:05 -0500

> doesn't it?  That's what the rfc actually requires for VERIFY/NVERIFY.

My apologies, yes, NVERIFY, VERIFY are that specific.  So let's
extend that error to OPEN, SETATTR, and CREATE.

That leaves GETATTR.  The wording for that operation is not as
specific and it allows for either ignoring the attribute and not
returning the value or returning _INVAL.  I would say that it is up
to the server implementation as to which is more appropriate.

Spencer