Oplock implementation - Is it correct??

John Winfield winfij at hotmail.com
Thu Jan 13 12:32:59 GMT 2000

Greetings all,

I've just been reviewing the (old) draft SMB spec and noticed a line in the 
exclusive oplock description section that made me think, so I checked the 
2.0.6 source code.

The sentences in question read:

<start quote>
If, at some point in the future, another client, such as client B, requests 
an open of the same file, or requests a path name based operation on the 
file, then the server MUST tell client A to relinquish its exclusive oplock. 
If client B's request will not modify the state of the file, the server MAY 
tell client A that its exclusive oplock has been replaced by a level II 
<end quote>

The interesting part is the mention of the requirement to break an oplock if 
another client performs a path name based operation on a file oplocked by 
another client.

I checked the implementation of the call_trans2setfilepathinfo function and 
could find no mention of breaking oplocks. This call could potentially 
truncate the file another client has oplocked and cached locally, correct??

I'd be interested to hear others thoughts on this. I may be barking up the 
wrong tree here....


John Winfield

Get Your Private, Free Email at http://www.hotmail.com

More information about the samba-technical mailing list