Editing Server Message Block (section)

=== Opportunistic locking ===
In the SMB protocol, opportunistic locking is a mechanism designed to improve performance by controlling [[cache (computing)|caching]] of network files by the client.<ref>{{cite web|date=May 31, 2018|title=Opportunistic Locks|url=https://docs.microsoft.com/en-us/windows/win32/fileio/opportunistic-locks|access-date=August 19, 2021|publisher=Microsoft|archive-date=August 19, 2021|archive-url=https://web.archive.org/web/20210819174457/https://docs.microsoft.com/en-us/windows/win32/fileio/opportunistic-locks|url-status=live}}</ref> Unlike traditional [[Lock (computer science)|locks]], opportunistic lock (OpLocks) are not strictly [[file locking]] or used to provide mutual exclusion.

There are four types of opportunistic locks.

; Batch Locks: Batch OpLocks were created originally to support a particular behavior of DOS batch file execution operation in which the file is opened and closed many times in a short period, which is a performance problem. To solve this, a client may ask for an OpLock of type "batch". In this case, the client delays sending the close request and if a subsequent open request is given, the two requests cancel each other.<ref name="Sphere2014">{{cite web|year=2014|title=All About Opportunistic Locking|url=https://sphereit.uk/all-about-opportunistic-locks/|access-date=August 19, 2021|website=Sphere IT|archive-date=August 19, 2021|archive-url=https://web.archive.org/web/20210819154425/https://sphereit.uk/all-about-opportunistic-locks/|url-status=live}}</ref>
; Level-1 OpLocks / Exclusive Locks: When an application opens in "shared mode" a file hosted on an SMB server which is not opened by any other process (or other clients) the client receives an '''exclusive OpLock''' from the server. This means that the client may now assume that it is the only process with access to this particular file, and the client may now cache all changes to the file before committing it to the server. This is a performance improvement, since fewer round-trips are required in order to read and write to the file. If another client/process tries to open the same file, the server sends a message to the client (called a ''break'' or ''revocation'') which invalidates the exclusive lock previously given to the client. The client then flushes all changes to the file.
; Level-2 OpLocks: If an exclusive OpLock is held by a client and a locked file is opened by a third party, the client has to relinquish its exclusive OpLock to allow the other client's write/read access. A client may then receive a "Level&nbsp;2 OpLock" from the server. A Level&nbsp;2 OpLock allows the caching of read requests but excludes write caching.
; Filter OpLocks: Added in Windows NT 4.0, Filter Oplocks are similar to Level&nbsp;2 OpLocks but prevent sharing-mode violations between file open and lock reception. Microsoft advises use of Filter OpLocks only where it is important to allow multiple readers and Level&nbsp;2 OpLocks in other circumstances. Clients holding an OpLock do not really hold a lock on the file, instead they are notified via a ''break'' when another client wants to access the file in a way inconsistent with their lock. The other client's request is held up while the break is being processed.
; Breaks: In contrast with the SMB protocol's "standard" behavior, a break request may be sent ''from'' server ''to'' client. It informs the client that an OpLock is no longer valid. This happens, for example, when another client wishes to open a file in a way that invalidates the OpLock. The first client is then sent an OpLock break and required to send all its local changes (in case of batch or exclusive OpLocks), if any, and acknowledge the OpLock break. Upon this acknowledgment the server can reply to the second client in a consistent manner.