RE: what is a server to do... (current filehandle != file/stateid )

New Message Reply About this list Date view Thread view Subject view Author view Attachment view

From: Noveck, Dave (Dave.Noveck@netapp.com)
Date: 01/23/03-02:27:00 PM Z


Message-ID: <C8CF60CFC4D8A74E9945E32CF096548A072A3B@SILVER.nane.netapp.com>
From: "Noveck, Dave" <Dave.Noveck@netapp.com>
Subject: RE: what is a server to do... (current filehandle != file/stateid )
Date: Thu, 23 Jan 2003 12:27:00 -0800

> So it is possible that a client makes a mistake and sends over a
> request such that the current filehandle does not match the
> file/stateid for a particular operation.  What should a server do?

> Our server is currently returning NFS4ERR_BAD_STATEID.

That's what our server does as well.  My logic is that in the current 
context, as set by the current file handle, that stateid isn't valid.  

> At one point
> this seemed appropriate since the client had just made a mis-match
> error in constructing its request.

> The alternate choice is to have the server return another error.
> NFS4ERR_INVAL seems most appropriate since we don't have a
> NFS4ERR_FILEHANDLE_STATEID_MISMATCH error.  The implication in
> returning NFS4ERR_INVAL is that the server will need to bump the
> sequence id.  This seems odd to me since there is a mismatch error in
> the request but I am not wedded to one method or the other.

INVAL is kind of annoying since it tells you something is wrong
without any hint about what.

And bumping the sequence-id when somebody sent you something 
erroneous doesn't seem very nice either.

Given that the spec is silent on this, one can't say that the
server is wrong to return INVAL, but likewise a strong case can
be made for BAD_STATEID.  So, given that, I would say that both
are valid (i.e. a testing program should accept both) and I 
can't see that client implementations will really depend on 
which error is returned when they do this.

Even though both are OK, my subjective feeling is that 
BAD_STATEID is "better".  

> The operations that would have this check all have NFS4ERR_INVAL
> available to them and obviously not all have to deal with incrementing
> the sequence id.  CLOSE, DELEGRETURN, LOCK, LOCKU, OPEN_CONFIRM,
> OPEN_DOWNGRADE, READ, SETATTR, WRITE
>
> Opinions?


New Message Reply About this list Date view Thread view Subject view Author view Attachment view

This archive was generated by hypermail 2.1.2 : 03/04/05-01:50:47 AM Z CST