FSCTL_REQUEST_FILTER_OPLOCK IOCTL (winioctl.h)
ファイルに対してフィルターの便宜的ロックを要求します。
この操作を実行するには、次のパラメーターを使用して DeviceIoControl 関数を呼び出します。
BOOL DeviceIoControl(
(HANDLE) hDevice, // handle to file
FSCTL_REQUEST_FILTER_OPLOCK, // dwIoControlCode
NULL, // lpInBuffer
0, // nInBufferSize
NULL, // lpOutBuffer
0, // nOutBufferSize
(LPDWORD) lpBytesReturned, // number of bytes returned
(LPOVERLAPPED) lpOverlapped // OVERLAPPED structure
);
解説
この操作は、ローカル サーバーから日和見ロックを要求するクライアント アプリケーションでのみ使用されます。 リモート サーバーから日和見ロックを要求するクライアント アプリケーションは、それらを直接要求してはなりません。ネットワーク リダイレクターは、アプリケーションの日和見ロックを透過的に要求します。 この操作を使用してリモート サーバーから日和見ロックを要求しようとすると、要求が拒否されます。
新しい oplock 型が必要な場合は、ハンドルを閉じ、CreateFile を使用して新しいハンドルを再度開き、必要なFSCTL_REQUEST_OPLOCK_XXXコントロール コードを使用して新しいハンドルで DeviceIoControl を呼び出す必要があります。 oplock 型を変更できるハンドルに対して oplock を要求するには (ハンドルを閉じて再度開く必要はありません)、 FSCTL_REQUEST_OPLOCK コントロール コードを使用します。
FSCTL_REQUEST_FILTER_OPLOCKを使用して、ファイルに対するフィルターの日和見ロックを要求します。 クライアント ファイル システムは、フィルター ロックが保持されている限り、読み取りデータをキャッシュし、データをローカルで処理できますが、一度にロックを保持できるクライアントは 1 つだけです。
フィルター oplock の所有者は、フィルター oplock と互換性のない操作が別のハンドルで実行される前に、oplock の中断を確認する必要があります (「 日和見ロックの中断」を参照)。 ロックが解除されると、ネットワーク リダイレクターに、ファイルからキャッシュされたデータが有効と見なされないことが通知されます。
詳細については、「 日和見ロックの種類」を参照してください。
さまざまな oplock コントロール コードの比較については、「 FSCTL_REQUEST_OPLOCK」を参照してください。
FSCTL_REQUEST_FILTER_OPLOCKコントロール コードは、ファイルが重複しない (同期) モードで開かれている場合に失敗します。
この操作に対する重複した I/O の影響については、 DeviceIoControl トピックの「解説」セクションを参照してください。
Windows 8 および Windows Server 2012 では、このコードは次のテクノロジでサポートされています。
テクノロジ | サポートされています |
---|---|
サーバー メッセージ ブロック (SMB) 3.0 プロトコル | いいえ |
SMB 3.0 Transparent Failover (TFO) | No |
スケールアウト ファイル共有 (SO) を使う SMB 3.0 | No |
クラスターの共有ボリューム ファイル システム (CsvFS) | はい |
Resilient File System (ReFS) | はい |
要件
サポートされている最小のクライアント | Windows XP (デスクトップ アプリのみ) |
サポートされている最小のサーバー | Windows Server 2003 (デスクトップ アプリのみ) |
Header | winioctl.h (Windows.h を含む) |