Acknowledging Oplock Breaks

There are different types of acknowledgments that the owner of an oplock can return. Similar to the grant requests, these acknowledgments are sent as file system control codes (that is, FSCTLs). They are:

    • This FSCTL indicates that the oplock owner has completed stream synchronization and they accept the level to which the oplock was broken (either Level 2 or None).
    • This FSCTL indicates that the oplock owner has completed stream synchronization but does not want a Level 2 oplock. Instead, the oplock should be broken to None (that is, the oplock is to be relinquished entirely).
    • For a Level 1 oplock, this FSCTL indicates that the oplock owner has completed stream synchronization and is relinquishing the oplock entirely (no Level 2 oplock may result from this acknowledgment).
    • For a Batch or Filter oplock, this FSCTL indicates that the oplock owner intends to close the stream handle on which the oplock was granted. Operations blocked, awaiting acknowledgment of the oplock break, continue to wait until the oplock owner's handle is closed.
    • By specifying REQUEST_OPLOCK_INPUT_FLAG_ACK in the Flags member of the REQUEST_OPLOCK_INPUT_BUFFER structure passed as the lpInBuffer parameter of DeviceIoControl, this FSCTL is used to acknowledge breaks of Windows 7 oplocks. The acknowledgment is required only if the REQUEST_OPLOCK_OUTPUT_FLAG_ACK_REQUIRED flag is set in the Flags member of the REQUEST_OPLOCK_OUTPUT_BUFFER structure passed as the lpOutBuffer parameter of DeviceIoControl. In a similar manner, FltFsControlFile and ZwFsControlFile can be used to acknowledge Windows 7 oplocks from kernel-mode. For more information, see FSCTL_REQUEST_OPLOCK.

A related FSCTL code is FSCTL_OPLOCK_BREAK_NOTIFY. This code is used when the caller wants to be notified when an oplock break on the given stream completes. This call may block. When the FSCTL_OPLOCK_BREAK_NOTIFY call returns STATUS_SUCCESS, this signifies one of the following:

  • No oplock granted.

  • No oplock break was in progress at the time of the call.

  • Any oplock break that was in progress is now complete.

To send an acknowledgment when no acknowledgment is expected is an error and the acknowledgment FSCTL IRP is failed with STATUS_INVALID_OPLOCK_PROTOCOL.

Closing the handle of the file for which the oplock break is requested will implicitly acknowledge the break. In the case of an oplock break for a sharing violation, the oplock holder can close the file handle, which acknowledges the oplock break, and prevent a sharing violation for the other user of the file.



Send comments about this topic to Microsoft

© 2014 Microsoft