2012-02-06 142 views
9

ネットワーク共有上のファイルを監視するFileSystemWatcherがあります。おそらくネットワークの問題のためにシェアを利用できないようにするイベントが発生した場合、FileSystemWatcherは切断されます。FileSystemWatcherネットワーク切断

明らかに私は "エラー"イベントを処理することができます。おそらくいくつかのロギングを行い、多くの記事がFSWをエラーイベントハンドラの中に再接続することを提案します。

しかし、エラーイベント内でネットワーク共有がまだ使用できない場合はどうなりますか。次に、ネットワーク共有が利用可能かどうかをテストし、FSWに再接続を試みるタイマーを導入する必要があります。

1)良いアプローチがありますか?

2)FSWがファイルから切断されたことを確認できるプロパティはありますか? FSWの非公開メンバーである "stopListening"があり、FSWが切断されたときにtrueに設定されているように見えます。しかし、これは公に...

おかげ ケビン

+0

可能性の重複[FileSystemWatcherとネットワークの切断?]応答ERNO用(http://stackoverflow.com/questions/281573/filesystemwatcher-and-network-disconnect) –

+0

おかげで、ないそうではありませんありません。私は、エラーイベントを使用して再接続できることを知っています。しかし、エラーイベントが発生した場合、ネットワーク共有が利用できない場合はどうなりますか?再接続するためのタイマー/タイムアウト試行がない限り、私は再接続を試みる他のイベントはありません!また、FSWは公開されているプロパティを公開していないことを教えてくれます。 –

+0

投稿によると、私はあなたが使用できるエラーイベントがあることを示唆しています。タイマーは、可用性を調べるための良いアイデアです。 –

答えて

1

これをフォローアップします。 MSDNフォーラムのMicrosoftリソースの提案で、これをMicrosoft Connectに追加しました。マイクロソフトからのフィードバックから

キーポイント: - エラーイベントがあるだけでなく、内部バッファオーバーフローのため - 彼らは

リンクここでは、顧客の提案の自分のリストにStopListeningはプロパティを暴露の可能性を追加します。 http://connect.microsoft.com/VisualStudio/feedback/details/727934/filesystemwatcher-error-handling

+0

ページはもはや利用できないか、それを閲覧する権限はありません。 – Darren

7

育ち、私が入力したとして育ったコメントや提案のカップルを...(

任意の助けをいただければ幸いに露出していません...申し訳ありません)

FileSystemWatcherは非常に多くのイベントが発生したため、FileSystemWatcherが非常に迅速に処理され、すべて処理できません。 は、ファイルシステムの監視中にエラーが発生した場合(ネットワークの脱落など)、起動しません。

私は同様の状況があったと信じています。問題は、ネットワーク接続が切断されたときにFileSystemWatcherがイベントを発生させることはないということです。なぜなら、実際に見ているものを見ることができないからです。しかし、事実を認識していないようです。ネットワーク接続が復帰すると、FileSystemWatcherは回復しません。つまり、(復元された)接続はまだ表示されません。私たちが思いついた唯一の解決策は、定期的にFileSystemWatcherオブジェクト全体を削除し、新しいものを作成し、すべてのイベントと時計フォルダなどを設定するタイマーを持つことでした。新しいFileSystemWatcherを削除して作成すると比較的速く(すなわちミリ秒)、あなたはプロセッサをあまり使わずに10秒ごとに起動するようにタイマーを設定することができます。もちろん、ネットワークがまだ残っている場合、FileSystemWatcherは、あなたが何をしていてもネットワークを見ることができません。しかし、それはOKです。もう10秒後にもう一度試してみます。この溶液を用いたために注意すべき

2つのこと:タイマーが作動すると

  1. 、それはFileSystemWatcherが現在どのイベントも処理されていないことを確認する必要があり、それがある場合に待機する必要があります。したがって、タイマーイベントでは、タイマーを停止し、FileSystemWatcherのイベントを発生させないようにしてから、FileSystemWatcherイベントが完了するまで待ちます(ロック(...){...}を使用してこれを行うのが良い方法です)。
  2. FileSystemWatcherを削除して再作成した後、FileSystemWatcherのリフレッシュ中(またはネットワークがダウンしている間)に発生した可能性のあるイベントを手動で確認する必要があります。たとえば、FileSystemWatcherをリフレッシュしている間、またはネットワーク接続が切断されている間に、ファイルが作成されているのを見て、ファイルが作成されると、FileSystemWatcherの新しいインスタンスを起動すると、そのファイルのイベントは取得されませんファイルが既に作成されているため)。

私は役立つことを望みます。

+0

応答マークありがとう。 MSDNのドキュメントを再読み込みした後、あなたが正しいことがわかります。ファイルシステムを見ているときにエラーが発生しても、実際にはエラーイベントは発生しません。 –

+1

あなたのアプローチは興味深いですが(おそらく設計上の欠陥のため)、FileSystemWatcherは実際には大量のWCFサービス内の静的なものです。だから、10秒ごとにそれを再初期化しなければならないというコンセプトは、私たちにとってはおそらくオプションではないでしょう。エラーイベントに絶対に頼ることはできないので、答えがないように聞こえるが、最適な解決策は、信頼できないアプローチのように見えるため、FileSystemWatcherを削除するというソリューションを再調整することだろう。 –

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 
    } 
}); 
関連する問題