Precisions wanted on OP_WRITE with a stateid whose bits are all set to zero

[DENIEL Philippe]

Hi to all,

in RFC3530, on page 220-221 (describing OP_WRITE4), I can see

     For a WRITE with a stateid value of all bits 0, the server MAY allow
       the WRITE to be serviced subject to mandatory file locks or the
       current share deny modes for the file.  For a WRITE with a stateid

    --- (page 221 begins here)

       value of all bits 1, the server MUST NOT allow the WRITE operation to
       bypass locking checks at the server and are treated exactly the same
       as if a stateid of all bits 0 were used.

Are NFSv4 clients from the linux kernel subject to perform WRITE with 
such 'all 0' or 'all 1' stateids ? (I am running a Fedora 9 with updated 
kernel 2.6.25.9-76 as client).
The situation is a bit confusing to me: should a 'all 0 stateid' write 
bypass all locks and shares or just locks and respect shares. I do not 
clearly understand the difference between a 'all 1' stateid and a 'all 
0' stateid as well. Should these special values mean that the last 
stateid (the one from the last OP_OPEN) is to be used instead, this 
value would be kind of "jokers" ?

Thank you for helping me, I feel a bit lost on this point (in fact I 
discovered that in the 'all 0 stateid case', my server systematically 
return 10023 aka NFS4ERR_STALE_STATEID which is clearly a very bad idea: 
the client loops on the OP_WRITE and the only way to put the NFSv4 
client in a correct state again is to reboot it....)

    Philippe