Subject: [nfsv4] SEEK Return value

From: Anna Schumaker <[email-masked]>
Date: Wed, 13 Nov 2013 16:34:00 -0500

Section 14.11.3 says "If the server could not find a corresponding sa_what, then the status would still be NFS4_OK, but sr_eof would be TRUE...".  Why don't we return NFS4ERR_UNION_NOTSUPP or some other error when the client passes a value other than NFS4_CONTENT_DATA, NFS4_CONTENT_HOLE or NFS4_CONTENT_APP_DATA_HOLE?

Anna

---

From: Anna Schumaker <[email-masked]>
Date: Wed, 13 Nov 2013 16:37:23 -0500

> Section 14.11.3 says "If the server could not find a corresponding sa_what, then the status would still be NFS4_OK, but sr_eof would be TRUE...".  Why don't we return NFS4ERR_UNION_NOTSUPP or some…

Probably because it means finding it within the file, and not in the data_content4 enum.  Never mind!

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

---

From: "Noveck, David" <[email-masked]>
Date: Thu, 14 Nov 2013 10:04:21 -0500

> Probably because it means finding it within the file, and not in the data_content4 enum.  Never mind!

OK, but there still is an issue here worth mentioning.

When you say,

> Why don't we return NFS4ERR_UNION_NOTSUPP or some other error when the client 
> passes a value other than NFS4_CONTENT_DATA, NFS4_CONTENT_HOLE or 
> NFS4_CONTENT_APP_DATA_HOLE?

The interesting question is "what error?"

As I read the spec now that error would be NFS4ERR_INVAL.  I think it would make more sense
to explicitly state that NFS4ERR_UNION_NOTSUPP is to be returned in this case.  That would make
it easier to extend the protocol to add content types, and allow new clients to easily interact
with existing servers that don't support the new types.  The client would get a clean indication
that the content type is not supported.  We should do this for WRITE_PLUS also.

---

From: Anna Schumaker <[email-masked]>
Date: Thu, 14 Nov 2013 10:19:00 -0500

> that the content type is not supported.  We should do this for WRITE_PLUS also.

Can we also change the paragraph that confused me to keep other implementers from getting confused as well?  Something like "If the server could not find a corresponding sa_what within the file" should be good enough.

---

From: "Noveck, David" <[email-masked]>
Date: Thu, 14 Nov 2013 10:27:57 -0500

> "If the server could not find a corresponding sa_what within the file" should be good enough.

Makes sense to me.

-----Original Message-----
From: Anna Schumaker [mailto:[email-masked]] 
Sent: Thursday, November 14, 2013 10:19 AM
To: Noveck, David
Cc: nfsv4 list ([email-masked])
Subject: Re: [nfsv4] SEEK Return value

On 11/14/2013 10:04 AM, Noveck, David wrote:
>> Why don't we return NFS4ERR_UNION_NOTSUPP or some other error when 
>> the client passes a value other than NFS4_CONTENT_DATA, 
>> NFS4_CONTENT_HOLE or NFS4_CONTENT_APP_DATA_HOLE?
> 
> As I read the spec now that error would be NFS4ERR_INVAL.  I think it 
> would make more sense to explicitly state that NFS4ERR_UNION_NOTSUPP 
> is to be returned in this case.  That would make it easier to extend 
> the protocol to add content types, and allow new clients to easily 
> interact with existing servers that don't support the new types.  The client would get a clean indication that the content type is not supported.  We should do this for WRITE_PLUS also.