問題タブ [filesystemwatcher]

監視対象ディレクトリ内のファイルの名前を変更するために FileSystemWatcher を使用しています。

この問題は、監視対象のディレクトリに同時にコピーされるファイルの数が 50 を超えると発生します...

名前変更イベントは最初の 50 個のファイルに対して正常に発生しますが、その後は何も起こりません

何か提案はありますか？

生の C++/WinAPI で .Net の FileSystemWatcher アナログが必要です。FindFirstChangeNotification/FindNextChangeNotification を使用して自分でコードを書き始めようとしましたが、これを必要とするのはおそらく私が初めてではなく、誰かが喜んで共有してくれるだろうと思いました。

理想的には、次のように使用できるクラスが必要です。

または、boost::signal のようなものを使用する場合は、さらに良いでしょう。ただし、標準ライブラリ、ブースト、生の WinAPI 以外に依存しないでください。ありがとう！

いくつかのグーグルをすることによって、私はそれが「ファイルシステムのアクションを追跡するために使用される」ことを知るようになりました。しかし、私はそれの有用性を理解していません、ウォッチャーはイベントを中間バッファーに保存せずに直接トリガーすることができます!!

イベントの非同期フロー（ファイルのコピー/変更）を同期イベント呼び出しに変換することはありますか？また、FileWatcherがイベントを非同期的にトリガーするかどうかもわかりません。

誰かがこれに光を当ててくれませんか？

VB.Net FileSystemWatcherクラスを使用して、Excelファイルの作成用のフォルダーを監視しようとしています。フォルダに.xlsファイルが作成されたときに応答がありますが、次のコードに問題があります。

このフォルダにテキストファイルを作成すると、適切なファイル名（ "C：\ Documents and Settings \ my.user \ Desktop \ tests \ foo.txt"）が返されます。ただし、Excelファイルをフォルダーに保存すると、パスは正しいのですが、ファイル名はガベージです（同じファイル名でも毎回異なり、常に「C：\ Documents andSettings \ my.user\Desktop」のように8文字です。 \ tests \ DE0B5800 "。）この検索Googleまたはここで何かを見つけることができません。いつものようにMSDNはほとんど役に立ちません。誰かが以前にこれに遭遇したり、私がより多くの情報を見つけることができる場所を知っていますか？

何らかの理由で、FileSystemWatcher からイベント ハンドラーを削除できません。

これは私が持っているものです

start を呼び出すと、変更イベントの受信を開始しますが、stop を呼び出すと、イベントが停止することを期待していますが、まだ発生しています。

ファイルが変更されたときにイベントをトリガーする filesystemwatcher があります。ロックが解除されたら、そのファイルから読み取りたいと思います。現時点では、イベントがトリガーされたらファイルを開こうとしています.大きなファイルがコピーされているとき、イベントが送信された後もしばらくの間ファイルロックがオンのままになり、ファイルが読み取りアクセスで開かれなくなります。

助言がありますか？

1. コレクション クリエーター クラスの create 関数を使用して、deepzoom タイルを一時フォルダーに保存しています。
2. DeepZoom タイルが作成される一時フォルダーに FilesystemWatcher クラスを設定しています。

プロジェクトをデバッグ モードで実行し、F10 を使用して ucode をデバッグすると、ファイルが変更されたという通知が表示されませんが、デバッグせずに F5 キーを押すと、「一時フォルダー内のファイルが変更されています」という通知イベントが表示されます。

Deepzoom タイルが完了したと確信している特定のイベントはありますか?それ以降は、FileSystemWatcher クラスのもののみを設定できます。

誰でも私を助けてもらえますか？

FileSystemWatcher を使用して新しいファイルのフォルダーを監視し、それらに対して何らかの処理を実行する、C# で記述された Windows フォーム アプリケーションがあります。私のアプリケーションはシステム トレイで実行するように設計されているため、起動時にフォームをインスタンス化しません。問題は、Created イベントが別のスレッドで発生し、Created イベントでフォームのインスタンスを作成しようとすると、SingleThreadApartment で実行する必要があることを示す ThreadStateException が発生することです。FileSystemWatcher.SynchronizingObject プロパティを設定する必要があると思いますが、アプリケーションにメイン フォームがないため、何を使用すればよいかわかりません。

典型的な FileSystemWatcher ソリューションを実装しようとしています。ファイルの作成を監視するディレクトリと、作成されたファイルを吸い上げてDBに挿入するタスクがあります。大まかに言えば、これには、数秒ごとに発生するバーストで 150 ミリ秒のレートで表示される 6 または 7、80 文字のテキスト ファイルの読み取りと処理が含まれ、まれに 2MB のバイナリ ファイルも処理する必要があります。これは、ほとんどの場合、24 時間年中無休のプロセスです。

FileSystemWatcher オブジェクトについて読んだことから、そのイベントをあるスレッドでキューに入れ、別のスレッドでそれらをデキュー/処理する方が良いでしょう。私が今持っている困惑は、処理を行うスレッドのより良い作成メカニズムは何であるかということです。私が見ることができる選択肢は次のとおりです。

1. FSW イベントを取得するたびに、手動で新しいスレッドを作成します (ええ、わかっています.. ばかげたアーキテクチャですが、言わなければなりませんでした)。

2. FSW イベントを取得するたびに、CLR スレッド プールで処理をスローします。

3. 起動時に、処理専用の 2 番目のスレッドを作成し、プロデューサー/コンシューマー モデルを使用して作業を処理します。メイン スレッドが要求をキューに入れ、2 番目のスレッドが要求をキューから取り出して作業を実行します。

ワークスレッドが常に必要になることがわかっているため、3番目の方法を優先する傾向があります。また、スレッドプールの感覚がないため、おそらくもっとそうです。

を使用してディレクトリを監視していFileSystemWatcherます。

ファイルがそのディレクトリにコピーされると、ウォッチャーはそれを取得し、それを使用して複数のアクションを実行します。

私の問題は、Microsoft Officeファイルを開くと、監視対象ディレクトリに一時ファイルが作成されることです。これらのファイルを無視する方法が見つかりません。

一時ファイル名はよく知られていますが（つまり、abcd.docx->〜$ cd.docx）、そのファイルを識別するには、これよりも優れた方法が必要です。

何か案は？