如何保持ReadDirectoryChangesW不會丟失文件更改

Question

當有大量文件活動時，互聯網上有很多關於ReadDirectoryChangesW API函數丟失文件的帖子。 大多數人都指責調用ReadDirectoryChangesW函數循環的速度。 這是一個不正確的假設。 我看到的最好的解釋是在下面的帖子，評論於2008年4月14日星期一下午2:15:27

http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/4465cafb-f4ed-434f-89d8-c85ced6ffaa8/

摘要是ReadDirectoryChangesW函數報告文件更改，因為它們離開文件后寫隊列，而不是添加它們。 如果在提交之前添加了太多，則會忽略其中一些。 如果您只是編寫一個程序來快速生成目錄中的1000多個文件，您可以通過實現看到這一點。 只需計算您獲得的文件事件通知數量，您就會看到有時您不會收到所有這些通知。

問題是，有沒有人找到一種可靠的方法來使用ReadDirectoryChangesW函數而不必每次都刷新卷？ 如果用戶不是管理員並且還可能需要一些時間來完成，則不允許這樣做。

Answer 1

我們從未見過ReadDirectoryChangesW 100％可靠。 但是，處理它的最佳方法是將“報告”與“處理”分開。

我的實現有一個只有一個作業的線程來重新排隊所有事件。 然后是第二個線程來處理我的中間隊列。 基本上，您希望盡可能少地阻止事件報告。

在高CPU情況下，您還可以阻止觀察者事件的報告。

Answer 2

如果API不可靠，那么解決方法可能是您唯一的選擇。 這當然可能涉及跟蹤lastmodified和filenames。 這並不意味着您需要在查找更改時進行輪詢，而是可以使用FileSystemWatcher作為觸發檢查的方法。

因此，如果您跟蹤ReadDirectoryChangesW / FSW事件發生的最后50-100次，並且您看到它被快速調用，您可以檢測到這一點並觸發特殊條件以獲取所有已更改的文件（並設置在幾秒鍾內暫時阻止未來的偽造FSW事件的旗幟。

由於有些人對此解決方案的評論感到困惑，我建議你應該監控事件從ReadDirectoryChangesW到達的速度，以及當它們到達速度太快時，嘗試嘗試解決方法（通常是手動掃描目錄）。

Answer 3

我遇到了同樣的問題。 但是，我沒有找到能夠保證獲得所有活動的解決方案。 在幾個測試中，我可以知道在GetQueuedCompletionStatus函數返回后應該盡快再次調用ReadDirectoryChangesW函數。 我想如果文件系統的處理速度比我的應用程序處理速度快得多，那么應用程序可能會丟失一些事件。

無論如何，我將一個解析邏輯與監控邏輯分開，並在一個線程上放置一個解析邏輯。