FileSystemWatcherネットワーク切断

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

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

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

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

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

どんな助けも高く評価されるでしょう...

ありがとう ケビン

9
追加された 著者 Erno de Weerd,
投稿によると、私はあなたが使用できるエラーイベントがあることを示唆した。タイマーは、可用性を調べるための良いアイデアです。
追加された 著者 Erno de Weerd,
レスポンスErnoに感謝しますが、そうではありません。私は、エラーイベントを使用して再接続できることを知っています。しかし、エラーイベントが発生した場合、ネットワーク共有が利用できない場合はどうなりますか?再接続するためのタイマー/タイムアウト試行がない限り、私は再接続を試みる他のイベントはありません!また、FSWは公開されているプロパティを公開しているわけではありません。
追加された 著者 Kevin Higgins,

3 答え

いくつかのコメントと提案...(私が入力していたように成長し、成長した...ごめんなさい)

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

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

このソリューションで注意すべき2つのこと:

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

私はそれが助けて欲しい

7
追加された
応答マークありがとう。 MSDNのドキュメントを再読み込みした後、あなたが正しいことがわかります。ファイルシステムを見ているときにエラーが発生しても、実際にはエラーイベントは発生しません。
追加された 著者 Kevin Higgins,
あなたのアプローチは面白いですが(おそらく設計上の欠陥のため)、FileSystemWatcherは実際には大量のWCFサービス内の静的なものです。だから、10秒ごとにそれを再初期化しなければならないというコンセプトは、私たちにとってはおそらくオプションではないでしょう。エラーイベントに絶対に頼ることはできないので、答えがないように聞こえるが、最適な解決策は、信頼できないアプローチのように見えるため、FileSystemWatcherを削除するというソリューションを再調整することだろう。
追加された 著者 Kevin Higgins,

これをフォローアップする。 MSDNフォーラムのMicrosoftリソースの提案で、これをMicrosoft Connectに追加しました。

Microsoftからのフィードバックの要点: - エラーイベントは、内部バッファオーバーフローだけでなく - 顧客提案のリストに stopListening プロパティを公開する可能性を追加します

Link here: http://connect.microsoft.com/VisualStudio/feedback/details/727934/filesystemwatcher-error-handling

1
追加された
ページがもはや利用できない、または閲覧する権限がない - 答えを無駄にする:
追加された 著者 Darren,
リンクはまだ悪いですが、これがどうして本当にあなたの質問に対する答えであったかは分かりません。
追加された 著者 topshot,

この作品のようなものではないでしょうか?私の簡単なテストケースのために働くようです。

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
    }
});
0
追加された