FSCTL_OPBATCH_ACK_CLOSE_PENDING - NtDoc
Native API online documentation, based on the System Informer
(formerly Process Hacker) phnt
headers
// winioctl.h
// CTL_CODE(0x0009, 0x004, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define FSCTL_OPBATCH_ACK_CLOSE_PENDING 0x00090010
View the official Win32 API reference// ntifs.h
// CTL_CODE(0x0009, 0x004, METHOD_BUFFERED, FILE_ANY_ACCESS)
#define FSCTL_OPBATCH_ACK_CLOSE_PENDING 0x00090010
View the official Windows hardware development documentationNo description available.
Notifies a server that a client application is ready to close a file. Use this operation after notification that an opportunistic lock on a file is ready to be broken.
To perform this operation, call the DeviceIoControl function by using the following parameters.
BOOL DeviceIoControl(
(HANDLE) hDevice, // handle to file
FSCTL_OPBATCH_ACK_CLOSE_PENDING, // dwIoControlCode
NULL, // lpInBuffer
0, // nInBufferSize
NULL, // lpOutBuffer
0, // nOutBufferSize
(LPDWORD) lpBytesReturned, // number of bytes returned
(LPOVERLAPPED) lpOverlapped // OVERLAPPED structure
);
Irp->IoStatus.Status is set to STATUS_SUCCESS if the request is successful.
Otherwise, Status to the appropriate error condition as a NTSTATUS code.
For more information, see NTSTATUS Values.
Before you call this function do not make assumptions about the number of available virtual channels, because the system and other plug-ins might have reserved virtual channels. Always check for a CHANNEL_RC_TOO_MANY_CHANNELS return code after calling this function.
For the implications of overlapped I/O on this operation, see the Remarks section of the DeviceIoControl topic.
Use the FSCTL_OPBATCH_ACK_CLOSE_PENDING control code when you are notified that an opportunistic lock on a file is ready to be broken, and you intend to close the file soon. This operation does not request a new opportunistic lock.
If you do not intend to close a file, you can use the FSCTL_OPLOCK_BREAK_ACKNOWLEDGE or FSCTL_OPLOCK_BREAK_ACK_NO_2 control code to respond to the notification. The former, used if the lock being broken is an exclusive opportunistic lock, indicates the file should receive a level 2 opportunistic lock instead. The latter requests the file be kept open but loses all locking.
Applications are notified that an opportunistic lock is broken by using the hEvent member of the OVERLAPPED structure that is associated with a file on which an opportunistic lock is broken. Applications can also use functions such as GetOverlappedResult and HasOverlappedIoCompleted.
In Windows 8 and Windows Server 2012, this code is supported by the following technologies.
| Technology | Supported |
|---|---|
| Server Message Block (SMB) 3.0 protocol | No |
| SMB 3.0 Transparent Failover (TFO) | No |
| SMB 3.0 with Scale-out File Shares (SO) | No |
| Cluster Shared Volume File System (CsvFS) | Yes |
| Resilient File System (ReFS) | Yes |
The FSCTL_OPBATCH_ACK_CLOSE_PENDING control code responds to notification that an exclusive (level 1, batch, or filter) opportunistic lock (oplock) on a file has been broken. A client application sends this control code to indicate that it acknowledges the oplock break and it is about to close the file handle.
For a batch or filter oplock break, the caller must close its file handle after sending this control code. Otherwise, the system will block waiting for the file handle to be closed.
This control code is not intended to be used with level 1 oplocks. Nevertheless, for a level 1 oplock break, the system treats this control code as a complete acknowledgment of the break, and the caller is not required to close the file handle.
This control code is rarely used. When a client application is notified of an oplock break for a file, and it closes its handle for the file, the system treats the file handle close as a complete acknowledgment of the oplock break. Thus it is never necessary to send this control code.
To process this control code, a minifilter calls FltOplockFsctrl with the following parameters. A file system or legacy filter driver calls FsRtlOplockFsctrl.
For more information about opportunistic locking and about the FSCTL_OPBATCH_ACK_CLOSE_PENDING control code, see the Microsoft Windows SDK documentation.
Oplock: Opaque oplock object pointer for the file.
CallbackData: FltOplockFsctrl only. Callback data (FLT_CALLBACK_DATA) structure for an IRP_MJ_FILE_SYSTEM_CONTROL FSCTL request. The FsControlCode parameter for the operation must be FSCTL_OPBATCH_ACK_CLOSE_PENDING.
Irp: FsRtlOplockFsctrl only. IRP for an IRP_MJ_FILE_SYSTEM_CONTROL FSCTL request. The FsControlCode parameter for the operation must be FSCTL_OPBATCH_ACK_CLOSE_PENDING.
OpenCount: Not used with this operation; set to zero.
FltOplockFsctrl always returns FLT_PREOP_COMPLETE for this operation.
FsRtlOplockFsctrl returns one of the following NTSTATUS values for this operation:
| Code | Meaning |
|---|---|
| STATUS_SUCCESS | The oplock held by this handle was in the process of being broken. |
| STATUS_INVALID_OPLOCK_PROTOCOL | No oplock was held by this handle, or the oplock break is not currently in progress. This is an error code. |
| Requirement type | Requirement |
|---|---|
| Header | Ntifs.h (include Ntifs.h or Fltkernel.h) |
FLT_PARAMETERS for IRP_MJ_FILE_SYSTEM_CONTROL
FSCTL_OPLOCK_BREAK_ACKNOWLEDGE