コマンドの出力をファイル（たとえば、echo Hello > file）にリダイレクトすると、コマンドが終了した直後にそのファイルにそのようなデータがあることが保証されますか？または、コマンド出口とファイルに書き込まれるデータの間に非常に小さなウィンドウがまだありますか？コマンドが終了した直後にファイルを読みたいのですが、空のファイルを読みたくありません。

関連するバッファ/キャッシュの複数の層があります。

1. CPUキャッシュ。

   データはバイトごとにまとめられ、CPUキャッシュに保存されます。CPUキャッシュがいっぱいで、データがしばらくアクセスされていない場合、データを含むブロックがメインメモリに書き込まれる可能性があります。これらは、ほとんどの場合、アプリケーションプログラマから隠されています。

2. インプロセスバッファ。

   データが収集されるプロセスにはいくつかのメモリが確保されているため、OSへのリクエストをできるだけ少なくする必要があります。これは比較的高価です。プロセスはデータをこれらのバッファにコピーしますが、これもCPUキャッシュによってバックアップされる可能性があるため、データがメインメモリにコピーされる保証はありません。アプリケーションは、たとえばfclose（3）またはfsync（3）を使用して、これらのバッファーを明示的にフラッシュする必要があります。exit（3）関数もプロセスが終了する前にこれを行いますが、_exit（2）関数はそうではありません。やっています。

3. カーネルバッファー

   その後、OSは独自のキャッシュを保持して、ディスクに送信する必要があるリクエストの数を最小限にします。このキャッシュは特にプロセスに属していないため、そこにあるデータはすでに終了したプロセスに属している可能性があり、すべてのアクセスがここを通過するため、次のプログラムはデータがここに到達すると表示されます。カーネルは、時間があれば、または明示的に要求されたときに、このデータをディスクに書き込みます。

4. ドライブキャッシュ

   ディスクドライブ自体もキャッシュを保持して、アクセスを高速化します。これらはかなり迅速に書き込まれ、キャッシュ内の残りのデータを書き込んで完了を報告するコマンドがあります。OSはシャットダウン時にこれを使用して、電源を切る前にデータが書き込まれないようにします。

アプリケーションでは、データをカーネルバッファーに登録するだけで十分です（実際のデータはこの時点でもCPUキャッシュに存在し、メインメモリに書き込まれていない可能性があります）。「エコー」プロセスは終了します。インプロセスバッファがフラッシュされ、データがOSに引き渡される必要があることを意味します。新しいプロセスを開始すると、要求されたときにOSが同じデータを返すことが保証されます。

アプリケーションに内部キャッシュがない場合、変更はすぐにファイルに書き込まれます。あなたの例でも同じです。ファイルはメモリ内の論理エンティティであり、すぐに更新されます。ファイルに対する以降の操作では、プログラムによる変更が表示されます。

ただし、これは変更が物理ディスクに書き込まれたことを意味しません。変更は、OSファイルシステムキャッシュまたはハードウェアキャッシュに残る場合があります。ファイルシステムバッファをフラッシュするには、sync次のコマンドを使用します。

コマンドが終了した直後にファイルを読みたいのですが、空のファイルを読みたくありません。

ここで実際的な問題に遭遇するべきではありません。

プロセスが終了すると、バッファは自動的にディスクにフラッシュされますか？

一般に、答えはノーです。

コマンドに依存します。他の回答が言及しているように、コマンドがデータを内部でバッファリングしない場合、コマンドが終了するとすべてのデータが利用可能になります。

しかし、すべてではありませんが、ほとんどの場合、標準I / Oライブラリはデフォルトで（ある程度まで）バッファ標準出力を行い、アプリケーションの終了時のバッファの自動フラッシュについて異なる保証を提供します。

Cは、通常の出口がバッファーをフラッシュすることを保証します。「通常の終了」とexitは、明示的に、またはから戻ることによって呼び出されることを意味しmainます。ただし、異常終了はこの呼び出しを回避できます（したがって、フラッシュされていないバッファーを残します）。

以下に簡単な例を示します。

#include <signal.h>
#include <stdio.h>

int main() {
    printf("test");
    raise(SIGABRT);
}

これをコンパイルして実行すると、必ずしもstdoutに書き込まれるtestとは限りません。

他のプログラミング言語では、さらに少ない保証しか提供していません。たとえば、Javaはプログラムの終了時に自動フラッシュしません。出力バッファーに未終了の行が含まれている場合、System.out.flush()明示的に呼び出されない限り、その行は失われる可能性があります。

データがファイルに到着した場合：それはあなたの質問の体がわずかに異なる何かを尋ね、言ったすべてで、それはすぐにコマンドが終了（他の回答で説明した警告の対象）の後にそうする必要があります。

まだこの問題に十分に取り組んでいる質問はないと思います。

コマンドが終了した直後にファイルを読みたいのですが、空のファイルを読みたくありません。

他の回答が説明しているように、正常に動作するプログラムは、プロセスが正常に終了する前に内部ファイルバッファーをフラッシュします。その後、データは永続ストレージに書き込まれる前に、カーネルまたはハードウェアバッファーに残っている可能性があります。ただし、Linuxのファイルシステムセマンティクスは、すべてのプロセスがカーネルが内部バッファーを含むのと同じ方法でファイルのコンテンツを表示することを保証します¹。

これは通常、ファイルオブジェクトごとに最大1つのカーネル内バッファを持ち、このバッファを通過するためにすべてのファイルアクセスを要求することで実装されます。

• プロセスがファイルを読み込む場合、要求されたファイル部分が現在バッファ内にある場合、カーネルはバッファの内容をプロセスに提示します。そうでない場合、カーネルは基礎となる記憶媒体からデータを取得してバッファ内に配置し、前の手順に戻ります。

• プロセスがファイルに書き込む場合、データは最初にそのファイルのカーネル内バッファ内に配置されます。最終的に、バッファの内容はストレージにフラッシュされます。その間に、同じバッファからの読み取りアクセスが満たされます（上記を参照）。

¹少なくとも通常のファイル、ディレクトリ、およびシンボリックリンクの場合。FIFOとソケットは、内容が永続的に保存されることは決してないため、別の問題です。内容がだれが尋ねるかによって決まる通常のファイルのいくつかの特別なケースがあります。例は、procfsおよびsysfs内のファイルです（/proc/selfこれは、シンボリックリンクを読み取るプロセスのプロセスIDへのシンボリックリンクであると考えてください）。

コマンドがCランタイムライブラリを使用するプログラムによって実行されると仮定すると、ある時点で呼び出しfcloseて開いているファイルを閉じる必要があります。

fcloseC関数のmanページには次のように書かれています：

注意fclose（）は、Cライブラリが提供するユーザー空間バッファのみをフラッシュすることに注意してください。データがディスクに物理的に保存されるようにするには、たとえばsync（2）またはfsync（2）を使用して、カーネルバッファーもフラッシュする必要があります。

のmanページにfflushも同じメモがあります。のmanページにcloseは次のように書かれています：

カーネルが書き込みを延期するため、正常に終了しても、データがディスクに正常に保存されたとは限りません。ストリームが閉じられたときにファイルシステムがバッファをフラッシュすることは一般的ではありません。データを物理的に保存する必要がある場合は、fsync（2）を使用してください。（この時点では、ディスクハードウェアに依存します。）

データはドライブと同期されていなくても、他のプロセスで使用できることに注意してください。多分それはあなたにとって既に十分であるかもしれません。

疑問がある場合は、テストを作成してください。

コマンドの出力をファイル（たとえば、echo Hello > file）にリダイレクトすると、コマンドが終了した直後にそのファイルにそのようなデータが含まれることが保証されますか？

はい。シェルは出力ファイルを開き、echoそこに直接出力します。コマンドが終了すると、完了です。

または、コマンド出口とファイルに書き込まれるデータの間に非常に小さなウィンドウがまだありますか？

データがすでにメディア上にあるかどうかは別の問題であり、それはその後ハードウェア障害が発生した場合にのみ問題になります。

コマンドが終了した直後にファイルを読みたいのですが、空のファイルを読みたくありません。

心配しないでください。カーネルは、開かれる頻度に関係なく、ファイルのビューを1つだけ保持します。

原則として、カーネルが所有するデータはすべて、カーネルによって維持およびクリーンアップされます。このようなデータには、などのシステムコールによってカーネルメモリに転送されたデータが含まれwrite(2)ます。

ただし、アプリケーション（たとえば、Cライブラリ）がこの上でバッファリングを実行する場合、カーネルは明らかにわからないため、クリーンアップを保証しません。

さらに、クリーンアップのタイミング保証はないと思います。一般に、「ベストエフォート」（「秒があるとき」を参照）ベースで実行されます。

または、コマンド出口とファイルに書き込まれるデータの間に非常に小さなウィンドウがまだありますか？

いいえ、ありません。

コマンドが終了した直後にファイルを読みたいのですが、空のファイルを読みたくありません。

コマンドの終了直後にファイルの最終的な内容を読み取ることができますが、代わりに空のファイルを読み取ることはありません。（CおよびC ++では、wait、waitpid、wait3またはwait4システムコールを使用して、プログラムが終了するのを待ってからファイルを読み取ります。シェル、別のプログラミング言語またはライブラリ（Cライブラリなど）を使用している場合システムまたはJava プロセスクラスを呼び出します）、おそらくこれらのシステムコールのいずれかを既に使用しています。）

他の回答とコメントが指摘しているように、プログラムが内部出力バッファーをフラッシュせずに終了した場合、プログラムの終了後に空のファイルを読み取ることになります（たとえば、_exit、中止または致命的なシグナルの受信、またはJavaプログラムが正常に終了します）。ただし、この時点でこれについてできることは何もありません。フラッシュされていないデータは永久に失われ、追加の待機では回復されません。

はい

別の余分な答えを追加してすみませんが、ほとんどは質問のタイトルの赤いニシンに焦点を当てているようです。しかし、私が知る限り、質問はバッファリングに関するものではなく、これです：

コマンドの出力をファイルにリダイレクトすると（たとえば、Hello> fileをエコー）、コマンドが終了した直後にそのファイルにそのようなデータがあることが保証されますか？

はい、無条件に。説明している「>」の使用方法と「|」「<」は、UnixおよびLinuxの世界が大きく基盤としているパイプベースの処理モデルです。すべてのLinuxインストールで、この動作に完全に依存する数千個ではないにしても、数百個のスクリプトがあります。

デザインごとに希望どおりに機能します。競合状態が発生する可能性がわずかでもあった場合、おそらく数十年前に修正されていました。