Subject: [nfsv4] Open with Claim_Delegate_Prev

From: [email-masked]
Date: Thu, 11 Dec 2003 16:17:52 -0500 (EST)

Can I ask about the one last open case?

I think I understand when the client will use it, but what does the client
expect in the reply?
- I currently return the recovered delegation (from before the SetClientID)
  but no related Open. (I just put the delegate stateid in both stateids in
  the reply.)

Does this sound correct or should I do an Open as well? (And if not, does
it matter what is returned in the first stateid?)

Thanks yet again for any help, rick

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

---

From: Trond Myklebust <[email-masked]>
Date: 11 Dec 2003 17:50:52 -0500

>>>>> " " == rick  <[email-masked]> writes:

     > Can I ask about the one last open case?  I think I understand
     > when the client will use it, but what does the client expect in
     > the reply?
     >   but no related Open. (I just put the delegate stateid in both
     >   stateids in the reply.)

     > Does this sound correct...

No. The same reasoning should apply to CLAIM_DELEGATE_PREV as applies
to CLAIM_DELEGATE_CUR, and all the other cases: the client is doing an
file OPEN call. It is issuing a request for a share mode, and an open
mode, and so "in normal circumstances" can only release state with a
CLOSE operation.

The only difference is that the client also wants to declare that it
believes it is the reincarnation of a client that once held a
delegation to that same file (that it might for instance have cached
modifications to) and so would also like to recover that delegation if
possible, pretty please.
AFAICS, it is perfectly correct for the server to reply NFS4_OK,
return a valid open stateid, but return OPEN_DELEGATE_NONE in the
delegation field (except in the case of CLAIM_PREVIOUS).
OTOH, returning a delegation but not an open stateid would appear to
be in conflict with the wording of the RFC. You would not be
respecting Windows share semantics etc.

Cheers,
  Trond