3 回答

TA貢獻1777條經(jīng)驗 獲得超10個贊
我看到文件系統(tǒng)觀察器在生產(chǎn)和測試環(huán)境中失敗了。我現(xiàn)在認為它很方便,但我認為它不可靠。我的模式是使用文件系統(tǒng)觀察程序來監(jiān)視更改,但偶爾進行輪詢以捕獲丟失的文件更改。
編輯:如果您有用戶界面,您還可以讓用戶“刷新”更改而不是輪詢。我會將它與文件系統(tǒng)觀察器結(jié)合起來。

TA貢獻1951條經(jīng)驗 獲得超3個贊
我遇到的最大問題是當(dāng)緩沖區(qū)滿了時丟失文件。很容易修復(fù) - 只需增加緩沖區(qū)。請記住,它包含文件名和事件,因此請將其增加到預(yù)期的文件數(shù)量(試用和錯誤)。它確實使用了無法分頁的內(nèi)存,因此如果內(nèi)存不足,它可能會強制其他進程進行分頁。
這是關(guān)于緩沖區(qū)的MSDN文章: FileSystemWatcher .. ::。InternalBufferSize屬性
每個MSDN:
增加緩沖區(qū)大小是昂貴的,因為它來自無法換出到磁盤的非分頁內(nèi)存,因此請盡可能減小緩沖區(qū)。要避免緩沖區(qū)溢出,請使用NotifyFilter和IncludeSubdirectories屬性過濾掉不需要的更改通知。
由于一次預(yù)計會有大量批次,我們使用16MB。工作正常,永遠不會錯過文件。
我們還在開始處理之前讀取了所有文件,即使只有一個......將文件名安全地緩存(在我們的例子中,放入數(shù)據(jù)庫表中)然后處理它們。
對于文件鎖定問題,我產(chǎn)生了一個進程,它等待文件解鎖等待一秒鐘,然后是兩秒鐘,然后是四個等等。我們從不投票。這已經(jīng)生產(chǎn)了大約兩年沒有錯誤。

TA貢獻1775條經(jīng)驗 獲得超8個贊
的FileSystemWatcher
也可能錯過在繁忙時間的變化,如果排隊改變的次數(shù)溢出提供的緩沖液中。這不是.NET類本身的限制,而是基礎(chǔ)Win32基礎(chǔ)結(jié)構(gòu)的限制。根據(jù)我們的經(jīng)驗,最小化此問題的最佳方法是盡快將通知出列并在另一個線程上處理它們。
如上面的@ChillTemp所述,觀察者可能無法處理非Windows共享。例如,它在安裝的Novell驅(qū)動器上根本不起作用。
我同意一個很好的折衷方案是偶爾進行民意調(diào)查,以便找出任何錯過的變化。
- 3 回答
- 0 關(guān)注
- 290 瀏覽
添加回答
舉報