2012-02-06 90 views
9

我有一個FileSystemWatcher監視網絡共享上的文件。如果發生事件使共享不可用(可能是由於網絡問題),FileSystemWatcher將斷開連接。FileSystemWatcher網絡斷開

很明顯,我可以處理「錯誤」事件,也許做一些日誌記錄和大量的文章建議重新連接錯誤事件處理程序內的FSW。

但是如果網絡共享在錯誤事件中仍然不可用,該怎麼辦?然後我需要引入一個計時器來測試網絡共享是否可用並嘗試重新連接FSW。

1)有沒有更好的方法?

2)是否有一個屬性可以讓我確定FSW已經脫離文件?我注意到有一個FSW「stopListening」的非公開成員,當FSW斷開連接時似乎設置爲true。但是,這不是公開暴露

任何幫助,將不勝感激......

感謝 凱文

+0

可能重複[FileSystemWatcher的網絡斷開?(http://stackoverflow.com/questions/281573/filesystemwatcher-and-network-disconnect) – 2012-02-06 14:58:23

+0

感謝您的答覆艾爾諾,但沒有事實並非如此。我知道我可以使用Error事件來重新連接。但是,當錯誤事件引發如果網絡共享不可用會發生什麼?除非我有某種計時器/定時嘗試重新連接,否則我沒有其他事件嘗試重新連接!此外,FSW不公開一個公共財產告訴我它已斷開連接 – 2012-02-06 16:56:54

+0

根據帖子,我建議您可以使用錯誤事件。計時器是探測可用性的好主意。 – 2012-02-06 18:10:01

回答

1

後續在此。在MSDN論壇上的Microsoft資源建議下,我將其添加到Microsoft Connect中。

從微軟反饋要點: - 錯誤事件不僅是對內部緩衝區溢出 - 他們將增加的stopListening財產暴露在他們的客戶的建議名單

鏈接在這裏的可能性: http://connect.microsoft.com/VisualStudio/feedback/details/727934/filesystemwatcher-error-handling

+0

頁面不再可用或沒有權限查看它 - 呈現無效的答案:( – Darren 2017-05-29 12:27:31

7

一對夫婦的意見和建議......(這越做越大,因爲我打字...對不起)

FileSystemWatcher.Error事件在FileSystemWatcher發生如此之多的事件以至於無法處理它們全部時觸發。它不會當觀看文件系統發生錯誤(如網絡輟學)時被觸發。

我相信我有過類似的情況。問題是,當網絡連接斷開時,FileSystemWatcher將永遠不會觸發事件,因爲它實際上看不到它應該看到的內容,但它似乎沒有意識到這一事實。當網絡連接恢復時,FileSystemWatcher不會恢復 - 即它仍然看不到(已恢復)連接。我們提出的唯一解決方案似乎可靠地工作,就是擁有一個定時器,定時器會定期刪除整個FileSystemWatcher對象並創建一個新對象,設置所有事件和監視文件夾等。由於刪除並創建一個新的FileSystemWatcher(相對)快(即毫秒),您可以將計時器設置爲每10秒左右激活一次,而無需佔用太多​​的處理器。當然,如果網絡仍然不存在,無論您做什麼,FileSystemWatcher都無法看到網絡。但沒關係,它會在10秒內再試一次。

有兩點需要注意與此解決方案:

  1. 當計時器激活,它需要檢查FileSystemWatcher的當前沒有處理任何事件,它需要等待,如果它是。因此,在計時器事件中,停止Timer,停止FileSystemWatcher引發事件,然後等待FileSystemWatcher事件完成(使用lock(...){...}是執行此操作的好方法)。
  2. 刪除並重新創建FileSystemWatcher後,需要手動檢查FileSystemWatcher刷新時(或網絡關閉時)可能發生的任何事件。例如,如果您正在監視正在創建的文件,並且在刷新FileSystemWatcher時或網絡連接斷開時創建了一個文件,則在啓動FileSystemWatcher的新實例時,不會爲這些文件獲取事件(因爲這些文件已經被創建)。

我希望有所幫助。

+0

感謝Mark的迴應。重新閱讀MSDN文檔後,我發現你是正確的,當觀看文件系統時發生錯誤時,錯誤事件實際上並未被觸發,這是我的錯誤理解。 – 2012-02-27 11:20:04

+1

然而,您的方法很有趣(可能是由於設計缺陷),FileSystemWatcher實際上是高容量WCF服務中的靜態內容。因此,必須每10秒重新初始化一次的概念對我們來說可能不是一種選擇,即使輕微的性能下降對我們所需的響應時間而言可能代價高昂。這聽起來好像沒有答案,因爲我們不能完全依賴錯誤事件,所以最佳解決方案是重新分解我們的解決方案以刪除FileSystemWatcher,因爲它似乎是一種不可靠的方法。 – 2012-02-27 11:28:45

0

會不會這樣的工作?似乎適用於我的簡單測試用例。的

var fsw = new FileSystemWatcher("[folder]", "*.*") { IncludeSubdirectories = true}; 
var fsw_processing = false; 
fsw.Deleted += (s, e) => 
{ 
    fsw_processing = true; 
    fsw.EnableRaisingEvents = false; 
    //...... 
    fsw.EnableRaisingEvents = true; 
    fsw_processing = false; 
};  
fsw.Changed += (s, e) => 
{ 
    fsw_processing = true; 
    fsw.EnableRaisingEvents = false; 
    //...... 
    fsw.EnableRaisingEvents = true; 
    fsw_processing = false; 
};  
//governor thread to check FileSystemWatcher is still connected. 
//It seems to disconnects on network outages etc. 
Task.Run(() => 
{ 
    while (true) 
    { 
     if (fsw.EnableRaisingEvents == false && fsw_processing == false) 
     {       
      try 
      {fsw.EnableRaisingEvents = true;} 
      catch (Exception) { fsw.EnableRaisingEvents = false; }    
     } 
     System.Threading.Thread.Sleep(1000 * 10);//sleep 10 secs 
    } 
});