21

多くのファイル アクティビティがある場合に、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 関数を使用する信頼できる方法を見つけた人はいますか? ユーザーが管理者でない場合、これは許可されず、完了までに時間がかかる場合もあります。

4

3 に答える 3

1

API の信頼性が低い場合は、回避策が唯一の選択肢になる可能性があります。もちろん、これには、lastmodified とファイル名を追跡することが含まれます。 これが意味するのは、変更を探すときにポーリングする必要があるということではなく、チェックをトリガーする手段として FileSystemWatcher を使用できるということです。

したがって、ReadDirectoryChangesW /FSWイベントが発生した最後の 50 ～ 100 回を追跡し、それが急速に呼び出されていることがわかった場合、これを検出して特別な条件をトリガーして、変更された (および設定された) すべてのファイルを取得できます。将来の偽の FSW イベントを一時的に防止するためのフラグ) を数秒で送信します。

このソリューションに関するコメントで混乱している人もいるので、ReadDirectoryChangesW からのイベントの到着速度を監視し、到着が速すぎる場合は、回避策 (通常はディレクトリの手動スイープ) を試みることを提案します。

于 2008-09-11T18:34:39.680 に答える
1

ReadDirectoryChangesW が 100% 信頼できることはこれまでありません。しかし、それを処理する最善の方法は、「報告」と「処理」を分離することです。

私の実装には、すべてのイベントを再キューイングするためのジョブが 1 つしかないスレッドがあります。次に、中間キューを処理するための 2 番目のスレッド。基本的に、イベントの報告をできるだけ妨げないようにしたいと考えています。

CPU 使用率が高い状況では、ウォッチャー イベントのレポートを妨げることもあります。

于 2013-10-01T15:13:10.073 に答える
0

私は同じ問題に遭遇しました。しかし、すべてのイベントを取得することを保証する解決策は見つかりませんでした。いくつかのテストで、GetQueuedCompletionStatus 関数が返された後、できるだけ早く ReadDirectoryChangesW 関数を再度呼び出す必要があることがわかりました。ファイルシステムの処理速度がアプリケーションの処理速度よりも非常に速い場合、アプリケーションはいくつかのイベントを失う可能性があると思います。

とにかく、解析ロジックを監視ロジックから分離し、解析ロジックをスレッドに配置しました。

于 2012-05-24T08:17:22.483 に答える