Oplocks do not break things. Oplocks will guarantee consistency. They are granted when only one client OS has a file open letting that client OS perform locking and caching operations internally without consulting the server each time. If another client wants to open the file, then that second open request is held up by the server, the first client contacted and asked to flush any outstanding data, acquire locks, and drop the oplock. Once that has happened then the second client gets the answer to its open request.
How is the first client 'contacted' and asked to respond? I can't see how this is anything but useless. I can't imagine very many programs honor this kind of request since I've never even heard of this before last week. If the first client doesn't respond to the request it would have to degenerate to a standard lock. Is this an OS hack designed in for a specific microsoft application?
There are other forms of oplocks that allow for opening and closing the file multiple times without consulting the server as well as some forms of limiting sharing (dropped when clients start using byte range locking). There have been some problems with Windows when smb signing is in use as the design of smb signing assumes request response pairs whereas oplock break notifications are asynchronous. Other than degenerate cases, current Windows versions have been patched.
Degenerate cases? This sounds like something only Microsoft could dream up, so I guess degenerate applies... ;) ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
