移動文件時，inotify將發出IM_MOVE_FROM,IN_MOVE_TO或兩者。在事件中有一個cookie字段，它允許我們確定鏈接事件。IN_MOVE_TO在inotify中是否直接跟隨IN_MOVE_FROM？
未指定的是鏈接的MOVE事件的順序以及MOVE_TO是否總是緊跟鏈接的MOVE_FROM（如果兩者均已發佈）。
他們之間可能還有其他事件嗎？
如果是，可能會有多個MOVE事件對混合在一起？
我知道這不是對您的確切問題的權威回答，但是想分享我們在watchman code中所做的工作，這些工作在大量Linux文件系統上進行了大量戰鬥測試，文件量大，速度快的變化。
我們的防守做如下假設：
因爲我們是一個bit的悲觀和inotify文檔中的措詞是不明確的，我們記錄cookie - >在地圖中移動信息，以便我們不依賴MOVE_TO直接在MOVE_FROM之後。這也有點複雜，因爲MOVE_FROM可能是一次讀取時適合讀取緩衝區的最後一個數據，而MOVE_TO可能是後續讀取的第一個數據。
只要我們從inotify流中消耗了所有可用數據（例如：非阻塞讀取返回0字節），我們就清除映射。該地圖中的任何內容都位於上面的（3.）類別中，並且將來不會顯示。
謝謝你的回答。這很有幫助。這並不容易，但您處理它的方式可以覆蓋所有情況。當你處理完事件並且地圖不是空的時候，你會做一個沒有阻塞的閱讀來檢查是否有更多的事件？你如何確定MOVE_TO是否缺席？在非常密集的inotify活動（創建/刪除10000個文件）的情況下，存在一個風險，即您必須等待很長時間直到發生讀取0事件。有沒有超時？如果我們可以假設MOVE_TO緊跟MOVE_FROM（如果存在）（最終在下一個讀取事件批次中），那將會更簡單。 – chmike
我鏈接到代碼，所以你可以看到我們爲自己做了什麼。 Watchman的模式是不直接跟蹤重命名，所以我們理想的情況是忽略這一點。但是，我們必須做一些基本的跟蹤，以瞭解inotify何時單方面更改了觀察描述符 - >名稱映射。 –