次の方法で共有

FSCTL_REQUEST_OPLOCK IOCTL (winioctl.h)

  • [アーティクル]

ファイルに対して便宜的ロック (oplock) を要求し、便宜的ロックの解除が発生したことを確認します。

この操作を実行するには、次のパラメーターを使用して DeviceIoControl 関数を呼び出します。

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

解説

この操作は、ローカル サーバーから日和見ロック (oplock) を要求するクライアント アプリケーションでのみ使用されます。 リモート サーバーから日和見ロックを要求するクライアント アプリケーションは、それらを直接要求してはなりません。ネットワーク リダイレクターは、アプリケーションの日和見ロックを透過的に要求します。 この操作を使用してリモート サーバーから日和見ロックを要求しようとすると、要求が拒否されます。

FSCTL_REQUEST_OPLOCKコントロール コードは、関連するコントロール コード (FSCTL_REQUEST_OPLOCK_LEVEL_1、FSCTL_REQUEST_OPLOCK_LEVEL_2、FSCTL_REQUEST_FILTER_OPLOCK、FSCTL_REQUEST_BATCH_OPLOCK) よりも効率的な機能を提供します。 異なる oplock レベルの要求は、 FSCTL_REQUEST_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 RW
FSCTL_REQUEST_OPLOCK_LEVEL_2 OPLOCK_LEVEL_CACHE_READ R

RequestedOplockLevel メンバーが設定されたFSCTL_REQUEST_OPLOCKコントロール コードを使用してOPLOCK_LEVEL_CACHE_READ | OPLOCK_LEVEL_CACHE_HANDLE、RH 型の oplock を許可します。 RH oplock は、 FSCTL_REQUEST_FILTER_OPLOCK コントロール コードによって付与されるフィルター oplock に似ています。 ただし、フィルター oplock では、一度に 1 つのファイルに対して oplock を保持できるクライアントは 1 つだけであることに注意してください。 FSCTL_REQUEST_OPLOCK を使用すると、一度に複数のクライアントがファイルに RH ロックを設定できます。 もう 1 つの違いは、 FSCTL_REQUEST_FILTER_OPLOCK 書き込みが発生する前に oplock ブレーク受信確認を必要とすることです。 ここで、oplock 中断通知はアドバイザリ専用であり、書き込みは受信確認なしで先に進むことができるため、FSCTL_REQUEST_OPLOCKでは行われません。 詳細については、「 Breaking Oplocks」を参照してください。

FSCTL_REQUEST_OPLOCKコントロール コードは、ファイルが重複しない (同期) モードで開かれている場合に失敗します。

この操作に対する重複した I/O の影響については、 DeviceIoControl トピックの「解説」セクションを参照してください。

Windows 8 および Windows Server 2012 では、このコードは次のテクノロジでサポートされています。

テクノロジ サポートされています
サーバー メッセージ ブロック (SMB) 3.0 プロトコル No
SMB 3.0 Transparent Failover (TFO) No
スケールアウト ファイル共有 (SO) を使う SMB 3.0 No
クラスターの共有ボリューム ファイル システム (CsvFS) はい
Resilient File System (ReFS) はい

また、Windows 8 および Windows Server 2012 以降では、 FSCTL_REQUEST_OPLOCK コントロール コードを使用して、ディレクトリとファイルの oplock を要求できます。 ディレクトリの oplock 要求では、RequestedOplockLevel メンバーで または OPLOCK_LEVEL_CACHE_READ | OPLOCK_LEVEL_CACHE_HANDLE をOPLOCK_LEVEL_CACHE_READ指定できます。

ディレクトリの列挙体の内容が変更されると、ディレクトリの R または RH oplock が None に切断されます。 たとえば、ディレクトリ内のファイルの追加/削除、ディレクトリ内のファイルのサイズの変更、ディレクトリ内のファイルのタイムスタンプの変更など、ディレクトリの oplock はすべて中断されます。 この oplock ブレークでは、ディレクトリ内の変更が発生する前に受信確認は必要ありません。これはアドバイザリ専用です。

ディレクトリ自体の名前が変更または削除されると、ディレクトリ上の RH oplock が R に切断されます。 この oplock ブレークでは、ディレクトリへの変更が発生する前に受信確認が必要です。

要件

   
サポートされている最小のクライアント Windows 7 [デスクトップ アプリのみ]
サポートされている最小のサーバー Windows Server 2008 R2 [デスクトップ アプリのみ]
Header winioctl.h (Windows.h を含む)

関連項目