Subject: Clarifications for section 8.6 -- Server Revocation of Locks

From: "Noveck, Dave" <[email-masked]>
Date: Mon, 25 Oct 1999 08:43:35 -0700

Now that I understand stateid's (I think I do anyway), I'm
going back and trying to clarify stuff that led me in the 
wrong direction and might lead other people astray.

We need to replace the last sentence of the penultimate
paragraph with the following:

    Similarly, the client must track operations which 
    will renew the lease period.  Using the time 
    that each such request was sent and the time that
    the corresponding reply was received, the client should
    bound the time that the corresponding renewal
    could have occurred on the server and thus determine
    if it is possible that a lease period expiration
    could have occurred. 

In the first sentence of the last paragraph, "has expired"
needs to be changed to "may have expired".

The last four sentences of the last paragraph need to be
revised as follows:

    Whenever it is possible that the lease period has
    expired, the client must validate each lock it has
    held to ensure that a conflicting lock has not been
    granted. The client may accomplish this task by 
    issuing an I/O request, either a pending I/O or a 
    zero-length read, specifying the stateid associated 
    with the lock in question.  If the response to the 
    request is success, the client has validated all of 
    the locks governed by that stateid and re-established
    the appropriate state between itself and the server.
    If the I/O request is not successful, then one or
    more of the locks associated with the stateid was
    revoked by the server and the client must notify
    the owner.