inotifyは、書き込みの開始時または完了時に通知を起動しますか？
ext3 fs上の通常のファイルを介して通信する2つのプロセス、リーダーとライターを想像してください。Reader IN_MODIFYにはファイルのinotify ウォッチがあります。ライターは、1回のwrite()呼び出しでファイルに1000バイトを書き込みます。Readerはinotifyイベントを取得fstatし、ファイルを呼び出します。リーダーには何が見えますか？ Readerがst_sizeファイルに対して少なくとも1000を取得するという保証はありますか？私の実験から、そうではないようです。 Readerが実際にread()1000バイトできるという保証はありますか？ これは、真剣にI / Oバウンドボックスで発生しています。たとえばsar、約1秒の待機時間を示します。私の場合、リーダーはを呼び出す前にinotifyイベントを取得してから10秒待ってから、stat結果が小さすぎます。 私が期待していたのは、ファイルの準備が整うまでinotifyイベントが配信されないことでした。私が実際に起こっていると思うのwrite()は、ライターでの呼び出し中にinotifyイベントが発生し、データが準備ができたときにシステム上の他のプロセスで実際に利用できることです。この場合、10秒では十分ではありません。 私は、カーネルが実際に私が推測している方法を実装していることの確認を探しているだけだと思います。また、おそらく、この動作を変更するオプションがありますか？ 最後に-この振る舞いを考えると、inotifyのポイントは何ですか？とにかく、イベントを取得した後、データが実際に利用可能になるまで、ファイル/ディレクトリをポーリングすることになります。それをずっとやっていて、inotifyを忘れることもあります。 *** 編集 ** * * さて、よくあることですが、私が実際にやっていることが理解できたので、私が見ている行動は実際に理にかなっています。^ _ ^ 私は実際に、ファイルが存在するディレクトリのIN_CREATEイベントに応答しています。したがって、実際には、ファイルの作成に応答してファイルをstat（）しています。必ずしもIN_MODIFYイベントではなく、後で到着する可能性があります。 コードを変更して、IN_CREATEイベントを取得したら、ファイル自体でIN_MODIFYにサブスクライブし、IN_MODIFYイベントを取得するまで実際にファイルを読み取ろうとしないようにします。ファイルへの書き込みを見逃す可能性のある小さなウィンドウがあることを認識していますが、最悪の場合、最大秒数後にファイルが閉じられるため、これは私のアプリケーションでは受け入れられます。