[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ietf-nfsv4
Subject:    Re: [nfsv4] Open with Claim_Delegate_Prev
From:       Trond Myklebust <trond.myklebust () fys ! uio ! no>
Date:       2003-12-11 22:50:52
Message-ID: shsvfonnf3n.fsf () guts ! uio ! no
[Download RAW message or body]

>>>>> " " == rick  <rick@snowhite.cis.uoguelph.ca> 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?
     > - 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...

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

_______________________________________________
nfsv4 mailing list
nfsv4@ietf.org
https://www1.ietf.org/mailman/listinfo/nfsv4



[prev in list] [next in list] [prev in thread] [next in thread]