ファイルを移動すると、inotifyはIM_MOVE_FROM,IN_MOVE_TOまたはその両方を発行します。イベントにはリンクされたイベントを判断するための値を持つCookieフィールドがあります。IN_MOVE_TOはinotifyのIN_MOVE_FROMの直後にありますか？
リンクされたMOVEイベントの順序と、MOVE_TOが常にリンクされたMOVE_FROM（どちらも発行されている場合）の直後にあるかどうかは指定されていません。
他のイベントがある可能性がありますか？
この場合、複数のイベントペアが混在している可能性がありますか。MOVE
これはあなたの正確な質問に対する正式な回答ではありませんが、大量のファイルと高いレートの大規模なLinuxマシンで非常に戦闘テストされたwatchman code変化の
我々の守備以下の仮定を行います。
を取得できない場合があります来ますinotifyドキュメントの文言はあいまいですが、MOVE_FROMの直後にあるMOVE_TOに依存しないように、cookie - > move情報をマップに記録します。 MOVE_FROMが1つの読み取りで読み取りバッファに収まる最後のデータであり、MOVE_TOが後続の読み取りの最初のデータである可能性があるため、もう少し複雑です。
inotifyストリームからすべての利用可能なデータを消費したときはいつでも、マップをパージします（たとえば、非ブロッキング読み出しは0バイトを返します）。その地図内のものは上記（3.）のカテゴリにあり、今後表示されません。
ありがとうございました。それは役に立ちました。それは簡単ではありませんが、すべてのケースをカバーするために継ぎ目を処理する方法です。イベントを処理し、マップが空ではない場合は、何もイベントがあるかどうかをチェックするためにnoneをブロックしないでください。 MOVE_TOが存在しないかどうかはどのように判断しますか？非常に集中的なinotifyアクティビティ（作成/削除された10000ファイル）の場合、read 0イベントが発生するまで長い間待たなければならないリスクがあります。タイムアウトはありますか？ MOVE_TOがMOVE_FROMの直後にあると仮定することができれば簡単になります（最終的には次の読み込みイベントバッチ内にあります）。 – chmike
私はコードにリンクしていますので、自分で何をするのか分かります。ウォッチマンのモデルは名前の変更を直接追跡しないため、これを無視するのが理想的です。しかし、inotifyがwatch descriptor - > name mappingを一方的に変更したときを理解するために、基本的なトラッキングを行う必要があります。 –