FlushFileBuffers 関数 (fileapi.h)
指定したファイルのバッファーがフラッシュされ、バッファーに入れたすべてのデータがファイルに書き込まれます。
構文
BOOL FlushFileBuffers(
[in] HANDLE hFile
);
パラメーター
[in] hFile
開いているファイルのハンドル。
ファイル ハンドルには、 GENERIC_WRITE アクセス権が必要です。 詳細については、「 ファイル のセキュリティとアクセス権」を参照してください。
hFile が通信デバイスへのハンドルである場合、関数は送信バッファーのみをフラッシュします。
hFile が名前付きパイプのサーバー側へのハンドルである場合、クライアントがバッファー内のすべてのデータをパイプから読み取るまで、関数は戻りません。
戻り値
関数が成功すると、戻り値は 0 以外になります。
関数が失敗した場合は、0 を返します。 詳細なエラー情報を得るには、GetLastError を呼び出します。
hFile がコンソール出力のハンドルである場合、関数は失敗します。 これは、コンソール出力がバッファーに格納されていないためです。 関数は FALSE を返し、GetLastError はERROR_INVALID_HANDLEを返します。
解説
通常、WriteFile 関数と WriteFileEx 関数は、オペレーティング システムがディスクまたは通信パイプに定期的に書き込む内部バッファーにデータを書き込みます。 FlushFileBuffers 関数は、指定したファイルのすべてのバッファー情報をデバイスまたはパイプに書き込みます。
システム内でのディスク キャッシュ操作により、多数の書き込みが個別に実行されている場合、ディスク ドライブ デバイスへの書き込みのたびに FlushFileBuffers 関数を使用すると非効率的になる可能性があります。 アプリケーションがディスクに対して複数の書き込みを実行していて、重要なデータが永続メディアに確実に書き込まれるようにする必要がある場合、アプリケーションは FlushFileBuffers を頻繁に呼び出す代わりにバッファーなしの I/O を使用する必要があります。 バッファーされていない I/O 用のファイルを開くには、FILE_FLAG_NO_BUFFERINGフラグとFILE_FLAG_WRITE_THROUGH フラグを指定して CreateFile 関数を呼び出します。 これにより、ファイルの内容がキャッシュされず、書き込みごとにメタデータがディスクにフラッシュされます。 詳細については、CreateFile のページを参照してください。
ボリューム上のすべての開いているファイルをフラッシュするには、ボリュームへのハンドルを使用して FlushFileBuffers を呼び出します。 呼び出し元には管理特権が必要です。 詳細については、「特別な特権を使用して実行する」を参照してください。
CreateFile を使用してボリュームを開く場合、lpFileName 文字列は \.\x: または \?\Volume{GUID} の形式にする必要があります。 ボリューム名には末尾の円記号を使用しないでください。これはドライブのルート ディレクトリを示しているためです。
Windows 8 と Windows Server 2012 では、この関数は、次のテクノロジによってサポートされています。
テクノロジ | サポートされています |
---|---|
サーバー メッセージ ブロック (SMB) 3.0 プロトコル | はい |
SMB 3.0 Transparent Failover (TFO) | はい |
スケールアウト ファイル共有 (SO) を使う SMB 3.0 | はい |
クラスターの共有ボリューム ファイル システム (CsvFS) | はい |
Resilient File System (ReFS) | はい |
例
例については、「 マルチスレッド パイプ サーバー」を参照してください。
要件
サポートされている最小のクライアント | Windows XP [デスクトップ アプリ | UWP アプリ] |
サポートされている最小のサーバー | Windows Server 2003 [デスクトップ アプリのみ | UWP アプリ] |
対象プラットフォーム | Windows |
ヘッダー | fileapi.h (Windows.h を含む) |
Library | Kernel32.lib |
[DLL] | Kernel32.dll |
関連項目
フィードバック
https://aka.ms/ContentUserFeedback」を参照してください。
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「フィードバックの送信と表示