通过

FSCTL_REQUEST_OPLOCK IOCTL （winioctl.h）

  • 项目

请求文件上的机会锁（oplock），并确认发生了作锁中断。

若要执行此作，请使用以下参数调用 DeviceIoControl 函数。

BOOL DeviceIoControl(
  (HANDLE) hDevice,                 // handle to file
  FSCTL_REQUEST_OPLOCK,             // dwIoControlCode
  (LPVOID) lpInBuffer,              // pointer to REQUEST_OPLOCK_INPUT_BUFFER
  (DWORD) nInBufferSize,            // size of input buffer
  (LPVOID) lpOutBuffer,             // pointer to REQUEST_OPLOCK_OUTPUT_BUFFER
  (DWORD) nOutBufferSize,           // size of output buffer
  NULL,                             // number of bytes returned
  (LPOVERLAPPED) lpOverlapped       // OVERLAPPED structure
);

言论

客户端应用程序使用此作从本地服务器请求机会锁（oplock）。 客户端应用程序不得直接从远程服务器请求机会锁，网络重定向程序以透明方式请求应用程序的机会锁。 使用此作从远程服务器请求机会锁将导致请求被拒绝。

如果 DeviceIoControl作返回错误代码 ERROR_IO_PENDING，则授予 oplock 请求。 如果返回任何其他错误代码，则未授予 oplock。 如果错误代码是警告值（如ERROR_CANNOT_GRANT_REQUESTED_OPLOCK），则扩展信息可能在 REQUEST_OPLOCK_OUTPUT_BUFFER 结构中可用。

当授予的 oplock 中断时，OVERLAPPED 结构中的事件对象将发出信号，并在 REQUEST_OPLOCK_OUTPUT_BUFFER 结构中返回信息。 OVERLAPPED 结构的 内部 成员将设置为 NTSTATUS 值，该值提供有关 oplock 如何中断的扩展信息。

重叠。内部值 意义
STATUS_SUCCESS
0x0		 该 oplock 被另一个文件系统作中断。
STATUS_OPLOCK_HANDLE_CLOSED
0x00000216		 由于用于请求该作的文件句柄已关闭，因此该 oplock 不再生效。 请注意，如果 oplock 中断是因为用于请求它的句柄已关闭，则无需确认中断，而不考虑 oplock 类型。
STATUS_OPLOCK_SWITCHED_TO_NEW_HANDLE
0x00000215		 oplock 仍在生效，但它不再与用于请求它的文件句柄相关联。 调用方对文件使用不同的句柄来请求新的 oplock，该句柄现在拥有该 oplock。

FSCTL_REQUEST_OPLOCK 控件代码提供的功能比以下相关控制代码更高效：FSCTL_REQUEST_OPLOCK_LEVEL_1、FSCTL_REQUEST_OPLOCK_LEVEL_2、FSCTL_REQUEST_FILTER_OPLOCK和 FSCTL_REQUEST_BATCH_OPLOCK。 使用 FSCTL_REQUEST_OPLOCK时，可以在同一个句柄上重复执行请求不同的 oplock 级别，而无需关闭并重新打开句柄;其他控制代码要求关闭句柄，然后使用 CreateFile 重新打开句柄，以便进行此类更改。 这可以通过在重新发出 FSCTL_REQUEST_OPLOCK 控制代码时作 REQUEST_OPLOCK_INPUT_BUFFER 结构的 RequestedOplockLevel 成员来实现。

下表总结了 FSCTL_REQUEST_OPLOCK 提供的 oplock 类型的缓存能力如何对应于级别 2、级别 1 和批处理 oplock。

替代控件代码 等效 RequestedOplockLevel 标志值 Oplock 类型
FSCTL_REQUEST_BATCH_OPLOCK OPLOCK_LEVEL_CACHE_READ \| OPLOCK_LEVEL_CACHE_WRITE \| OPLOCK_LEVEL_CACHE_HANDLE RWH
FSCTL_REQUEST_OPLOCK_LEVEL_1 OPLOCK_LEVEL_CACHE_READ \| OPLOCK_LEVEL_CACHE_WRITE 乌尔曼
FSCTL_REQUEST_OPLOCK_LEVEL_2 OPLOCK_LEVEL_CACHE_READ R

将 FSCTL_REQUEST_OPLOCK 控件代码与设置为 OPLOCK_LEVEL_CACHE_READ | OPLOCK_LEVEL_CACHE_HANDLE 的 requestedOplockLevel 成员一起使用，授予 RH类型的 oplock。 RH oplock 类似于由 FSCTL_REQUEST_FILTER_OPLOCK 控制代码授予的筛选器作锁。 但是，请注意，筛选器 oplock 一次只允许一个客户端在文件上保存 oplock;FSCTL_REQUEST_OPLOCK 允许多个客户端一次在文件中锁定 RH 锁。 另一个区别是，FSCTL_REQUEST_FILTER_OPLOCK 需要在写入发生前进行 oplock 中断确认，其中 FSCTL_REQUEST_OPLOCK 不是因为 oplock 中断通知是通知性的，并且允许写入在未确认的情况下继续。 有关详细信息，请参阅 中断 Oplocks。

如果文件以非重叠（同步）模式打开，则 FSCTL_REQUEST_OPLOCK 控制代码将失败。

有关此作中重叠 I/O 的影响，请参阅 DeviceIoControl 主题的“备注”部分。

在 Windows 8 和 Windows Server 2012 中，以下技术支持此代码。

科技 支持
服务器消息块 （SMB） 3.0 协议 不
SMB 3.0 透明故障转移 （TFO） 不
具有横向扩展文件共享的 SMB 3.0 （SO） 不
群集共享卷文件系统 （CsvFS） 是的
可复原文件系统 （ReFS） 是的

此外，从 Windows 8 和 Windows Server 2012 开始，FSCTL_REQUEST_OPLOCK 控制代码可用于请求目录和文件上的 oplock。 目录中的 oplock 请求可以在 RequestedOplockLevel 成员中指定 OPLOCK_LEVEL_CACHE_READ 或 OPLOCK_LEVEL_CACHE_READ | OPLOCK_LEVEL_CACHE_HANDLE。

当目录枚举的内容发生更改时，目录上的 R 或 RH作锁将中断为 None。 例如，在目录中添加/删除文件、更改目录中文件的大小、修改目录中文件的时间戳等都将破坏目录中的 oplock。 在目录中发生更改之前，此 oplock 中断不需要确认;它是仅限公告的。

当目录本身被重命名或删除时，目录上的 RH作锁会中断到 R。 在更改目录之前，此 oplock 中断确实需要确认。

要求

要求 价值
最低支持的客户端 Windows 7 [仅限桌面应用]
支持的最低服务器 Windows Server 2008 R2 [仅限桌面应用]
标头 winioctl.h （包括 Windows.h）

另请参阅