看守可以發送文件爲什麼改變？

Question

守望者是否能夠發佈到已配置的命令，爲什麼它正在向該命令發送文件？

例如：

1. 一個文件是新文件夾將可能是一個FILE_CREATE標誌;
2. 一個被刪除的文件會向FILE_DELETE標誌發送命令;
3. 是經過修改會發出FILE_MOD標誌文件等
4. 甚至當文件夾被刪除（因此文件項下）將據此發出FOLDER_DELETE參數命名的文件夾，以及一個FILE_DELETE的文件/ FOLDER_DELETE到那裏的文件夾

有沒有這樣的事情？

Answer 1

不，它不能這樣做。其原因是其設計非常重要的原因。 TL; DR是一個比你想象的更爲複雜的事情，因爲客戶可以正確處理這些單獨的事件，而在幾乎所有情況下，你都不需要它們。

大多數文件監視系統是抽象的，只是從系統特定的通知信息翻譯成一些常見的形式。他們不會很好地處理，或者根本不處理通知隊列，也不會爲他們的客戶提供一種可靠地響應這種情況的方法。

除此之外，文件系統可以在很短的時間內以及來自多個併發線程或進程的許多不同變化中受到影響。這使得這個區域非常容易出現TOCTOU難以管理的問題。例如，創建和寫入文件通常會導致關於文件及其包含的目錄的一系列通知。如果在此序列之後立即刪除文件（可能是構建步驟中的中間文件），那麼在您看到有關文件創建的通知時，很可能它已被刪除。

Watchman接收通知的輸入流並將其輸入到其文件系統的內部模型中：觀察文件的有序列表。每次收到通知時，看守都將其視爲應該去的信號，並查看報告已更改的文件，然後將該文件的條目移至最近的有序列表末尾。

當您向Watchman詢問關於文件系統的信息時，可能或甚至有可能仍有待處理的內核通知。爲了儘量減少TOCTOU並確保其狀態是最新的，守望者會生成一個synchronization cookie，並在響應您的查詢之前等待該通知可見。

的上述兩件事情結合意味着守望結果數據有兩個重要的屬性：

1. 你保證有觀察到您的查詢之前所發生
2. 您會收到最新信息的所有通知對於任何給定的文件只有一次在您的查詢結果中（更改結果合併在一起）

讓我們來談談溢出情況。如果您的系統無法跟上文件更改的速度（例如：您有一個大項目，並且正在快速創建和刪除文件以及系統負載很重），則操作系統無法滿足所有待處理項目分配給手錶的緩衝區資源中的通知。當發生這種情況時，它會吹動這些緩衝區併發送溢出信號。這意味着觀看API的客戶端已經錯過了一些事件並且不再與文件系統的狀態保持同步。如果該客戶端維護關於文件系統的狀態，則不再有效。

Watchman通過重新檢查觀察樹並綜合標記所有文件被更改來解決這種情況。這會導致客戶端的下一個查詢查看樹中的所有內容。我們將其稱爲新實例結果集，因爲它與您第一次查詢時獲得的結果集是相同的。我們在結果中設置了一個標誌，以便客戶知道發生了這種情況，並且可以採取適當措施來修復自己的狀態。您可以通過query parameters配置此行爲。

在這些新鮮例如結果集，我們不知道任何給定的文件是否真的改變與否（這是可能的，它在這樣的，我們無法通過lstat檢測的方式改變），即使我們能看到它的元數據發生了變化，我們不知道這種變化的原因。

可能有多個事件導致給定文件出現在看守所交付的結果中。我們不是單獨記錄它們，因爲我們無法用無限的歷史追蹤它們;想象一個整天每秒都會增量寫入一次的文件。我們是否每天爲其保留86400個更改條目並將這些條目交付給我們的客戶？如果有幾十萬這樣的文件呢？我們不得不截斷這些數據，並且在這一點上，數據的損失會降低你對此的推理能力。

在所有這一切的結尾，客戶端比嘗試讀取文件或查看其元數據更爲罕見，並且一般而言，他們只在文件停止時纔會這樣做改變。對於此用例，watchman-wait,watchman-make和trigger都有一個結算期的概念，導致更改通知在交付之前延遲到文件系統停止更改之後。