CF_OPEN_FILE_FLAGS列挙 (cfapi.h)
ファイルを開く際にさまざまなアクセス許可を要求するフラグ。
構文
typedef enum CF_OPEN_FILE_FLAGS {
CF_OPEN_FILE_FLAG_NONE = 0x00000000,
CF_OPEN_FILE_FLAG_EXCLUSIVE = 0x00000001,
CF_OPEN_FILE_FLAG_WRITE_ACCESS = 0x00000002,
CF_OPEN_FILE_FLAG_DELETE_ACCESS = 0x00000004,
CF_OPEN_FILE_FLAG_FOREGROUND = 0x00000008
} ;
定数
CF_OPEN_FILE_FLAG_NONE 値: 0x00000000 開いているファイル フラグはありません。 |
CF_OPEN_FILE_FLAG_EXCLUSIVE 値: 0x00000001 指定すると、 CfOpenFileWithOplock は 共有なし ハンドルを返し、RH を要求します (OPLOCK_LEVEL_CACHE_READ |OPLOCK_LEVEL_CACHE_HANDLE) ファイルの oplock。 いずれかのFILE_EXECUTEに対して開く通常の CreateFile 呼び出し |FILE_READ_DATA |FILE_WRITE_DATA |FILE_APPEND_DATA |DELETE (またはいずれかの/両方のGENERIC_READ |GENERIC_WRITE) は、「 解説 」セクションで説明されているように、共有の競合が原因で oplock を中断します。 oplock の所有者は完了し、確認します。 |
CF_OPEN_FILE_FLAG_WRITE_ACCESS 値: 0x00000002 指定すると、 CfOpenFileWithOplock は、FILE_READ_DATA/FILE_LIST_DIRECTORYおよびFILE_WRITE_DATA/FILE_ADD_FILE アクセス権を持つファイルまたはディレクトリを開こうとします。それ以外の場合は、FILE_READ_DATA/FILE_LIST_DIRECTORYを使用してファイルまたはディレクトリを開こうとします。 |
CF_OPEN_FILE_FLAG_DELETE_ACCESS 値: 0x00000004 指定すると、 CfOpenFileWithOplock は DELETE アクセス権を持つファイルまたはディレクトリを開こうとします。それ以外の場合は、ファイルを正常に開きます。 |
CF_OPEN_FILE_FLAG_FOREGROUND 値: 0x00000008 このフラグを使用する場合、 CfOpenFileWithOplock は oplock を要求しません。 これは、呼び出し元がフォアグラウンド アプリケーションとして機能している場合に使用する必要があります。 つまり、この API によって作成されたファイル ハンドルが他の呼び出し元に対して共有違反を引き起こすかどうかは気にせず、ファイルに既にある可能性のある oplock を壊す心配はありません。 そのため、oplock を要求せずにハンドルを開きます。 メモ: 既定の バックグラウンド 動作では、ファイル ハンドルを開くときに oplock が要求されるため、既に oplock がある場合は呼び出しが失敗し、後で共有違反を引き起こさないようにする必要がある場合はハンドルを閉じるように指定できます。 呼び出し元が CfOpenFileWithOplock にCF_OPEN_FILE_FLAG_EXCLUSIVEを指定しない限り、取得する oplock は OPLOCK_LEVEL_CACHE_READ (OPLOCK_LEVEL_CACHE_READ |OPLOCK_LEVEL_CACHE_HANDLE)、バックグラウンド アプリが通常必要とする共有違反保護はありません。 |
注釈
バックグラウンド アプリケーションでは、通常、ファイルに対して透過的に操作する必要があります。 特に、他の (フォアグラウンド) オープンに対する共有違反を引き起こさないようにしたいと考えています。 これを行うには、 (OPLOCK_LEVEL_CACHE_READ |OPLOCK_LEVEL_CACHE_HANDLE) などの oplock は、 CfOpenFileWithOplock でCF_OPEN_FILE_FLAG_EXCLUSIVEを使用して付与されます。 その後、要求された共有/アクセス モードがバックグラウンド アプリケーションのモードと競合する他のオープナーが付属している場合、バックグラウンド アプリケーションの oplock は中断されます。 これにより、バックグラウンド アプリでファイル ハンドルを閉じるよう求められます (Cf ハンドルの場合、無効になります。基になる実際のハンドルが閉じられました)。 バックグラウンド アプリがそのハンドルを閉じると、開くもう 1 つの要求は、共有違反に遭遇することなく続行されます。 これはすべて、oplock のOPLOCK_LEVEL_CACHE_HANDLE部分が原因で機能します。 CF_OPEN_FILE_FLAG_EXCLUSIVEを使用しない場合、oplock にはOPLOCK_LEVEL_CACHE_READ保護のみが含まれているため、共有違反の保護は提供されません。
CF_OPEN_FILE_FLAG_EXCLUSIVEが指定されていない場合、オープン はすべて共有 され、OPLOCK_LEVEL_CACHE_READ oplock が取得されます。
通常の CreateFile 呼び出しでは、oplock は中断されません。 通常の CreateFile で Cf ハンドルのアクセスと競合する共有モードが指定されている場合 (たとえば、通常の CreateFile でFILE_SHARE_READが指定されていない場合)、通常の CreateFile はERROR_SHARING_VIOLATIONで失敗します。 oplock は、他の呼び出し元が書き込みなどの競合する I/O を発行するまで中断しません。 その場合 、oplock の中断はアドバイザリのみです。
要件
要件 | 値 |
---|---|
サポートされている最小のクライアント | Windows 10バージョン 1709 [デスクトップ アプリのみ] |
サポートされている最小のサーバー | Windows Server 2016 [デスクトップ アプリのみ] |
Header | cfapi.h |