問題タブ [readdirectorychangesw]

特定のディレクトリの下にあるファイルが (直接的または間接的に) 変更されたときにコードに通知されるようにします。「変更」とは、ファイルの内容が変更されたり、名前が変更されたり、削除されたりするたびにコードに通知することを意味します。または新しいファイルが追加された場合。私のアプリケーションでは、何千ものファイルが存在する可能性があります。

私は FSEvents のように見えましたが、その技術概要には次のように書かれています。

注目すべき重要なポイントは、通知の粒度がディレクトリ レベルであるということです。ディレクトリ内の何かが変更されたことだけが通知され、何が変更されたかは通知されません。

また、次のようにも述べています。

また、ファイル システム イベント API は、特定のファイルがいつ変更されたかを検出するようには設計されていません。このような目的には、kqueues メカニズムの方が適切です。

ただし、特定のファイルで kqueue を使用するには、ファイルを開いてファイル記述子を取得する必要があります。何千ものファイル記述子を管理するのは現実的ではありません (また、オープン ファイル記述子の最大許容数を超える可能性があります)。

不思議なことに、Windows ではこのReadDirectoryChangesW()関数を使用できます。

では、Mac OS X で私が望むことをどのように行うことができるでしょうか? または、別の方法で尋ねられました:ReadDirectoryChangesW()ユーザー空間で Mac OS X に相当するものを作成するにはどうすればよいでしょうか (非常に効率的に行います)。

~10,000 のサブフォルダーを含むフォルダーがあります。

Linux API またはツールは、/SharedRoot などの下の任意のフォルダーの変更を監視できますか、またはフォルダーごとに inotify をセットアップする必要がありますか? （つまり、10k以上のフォルダーに対してこれを実行したい場合、私は負けます）。私はこの非効率的な方法の例をすでに見たことがあるので、そうだと思います。

私の問題：
最近アクティブな「プロジェクト」を一番上にして、フォルダを時系列で並べ替える必要があります。

ファイルが変更されると、そのファイルの上の各フォルダーは、ファイルと一致するように最終変更のタイムスタンプを更新する必要があります。遅延は大丈夫です。ファイル (通常は MS Excel) を開き、再度閉じると、ファイルの日付が上下することがあります。このため、ファイルが閉じられるまで待ってから、そのファイルのフォルダーをチェックのためにキューに入れ、しばらくしてから、そのフォルダー内の最新のファイルを探しに行きます。 Excel または同様のプログラムによって、元のタイムスタンプにすでにさかのぼることができます。また、同じフォルダーの複数のファイルが使用/作成された場合、そのフォルダーの親のタイムスタンプをバッファリングして、少なくとも 1 つの遅延更新に折りたたまれた一連の更新を取得することは理にかなっています。

Linux ソリューションを探しています。Windows サーバーで実行できるコードがいくつかあります。キューイング機能のほとんどはここにあります: http://github.com/sesam/FolderdateFollowsFiles/blob/master/FolderdateFollowsFiles/Follower.vb

利用可能な API:s
Windows の inotify に関連するものである ReadDirectoryChangesW は、フォルダーとそのサブツリー全体を監視できます。http://msdn.microsoft.com/en-us/library/aa365465(VS.85).aspxの bWatchSubtree を参照してください。

サンバ？
samba ソースにパッチを適用する可能性はありますが、おそらく既に利用可能なフックがあるのでしょうか? クライアント側 (さまざまな Windows バージョン) や、フォルダーを再帰的に更新するためのファイル アクティビティのスパイなど、他の可能性はありますか?

問題は次のとおりです。Win32 API ReadDirectoryChangesW関数を使用してディレクトリを監視しています。また、新しく作成されたファイルと変更されたファイルを区別する必要があります。しかし、問題があります... いつものように:(

ケース:

1. 新規/変更 ​​( ) のディレクトリを監視しFILE_NOTIFY_CHANGE_FILE_NAME | FILE_NOTIFY_CHANGE_SIZEます。問題:ファイルの作成後、新しいファイル イベント + ファイルの変更イベントがトリガーされます。しかし、私は1つだけ必要です。どうすればそれを回避できますか? ファイルが変更されると、必要なものが得られます:)。
2. 新しいファイル ( FILE_NOTIFY_CHANGE_FILE_NAME) のディレクトリのみを監視しています - 問題ありません。
3. 変更ファイル ( ) のディレクトリのみを監視しますFILE_NOTIFY_CHANGE_SIZE。問題:新しいファイルが作成されると、変更アクションがファイル作成イベントと共に起動されます。どうすればそれを回避できますか?

もちろん、いくつかの回避策を実装しました。しかし、私が説明した問題を処理するエレガントな方法があるかどうか知りたいです。

ReadDirectoryChangesW() を使用して Windows のディレクトリの下の変更を監視する C コードを開発しています。ReadDirectoryChangesW() と FILE_NOTIFY_INFORMATION 構造に関連する MSDN エントリ、および他のいくつかのドキュメントを読みました。この時点で、監視自体に明らかな問題はなく、複数のディレクトリを監視できました。問題は、この関数によって FILE_NOTIFY_INFORMATION 構造体に入れられるファイル名が正規のものではないことです。

MSDN によると、それらは長い形式でも短い形式でもかまいません。このケースを処理するために短いパス名と長いパス名の両方をキャッシュすることを提案する投稿をいくつか見つけました。残念ながら、Windows 7 システムでの私自身のテストによると、これは問題を解決するのに十分ではありません。これは、各ファイル名に 2 つの代替手段しかないためです。問題は、パス名で EACH COMPONENT が長い形式または短い形式のいずれかである可能性があることです。次のパス名はすべて同じファイルを参照できます。

c:\PROGRA~1\MYPROG~1\MYDATA~1.TXT

c:\PROGRA~1\MYPROG~1\MyDataFile.txt

c:\PROGRA~1\MyProgram\MYDATA~1.TXT

c:\PROGRA~1\MyProgram\MyDataFile.txt

c:\Program Files\MYPROG~1\MYDATA~1.TXT

...

cmd.exe を使用したテストからわかる限り、それらはすべて完全に受け入れられます。基本的に、各ファイルの有効なパス名の数は、パス名の構成要素の数に応じて指数関数的に増加します。

残念ながら、ReadDirectoryChangesW() は、各操作を引き起こすシステム コールに提供されたファイル名で出力バッファを埋めているようです。たとえば、cmd.exe コマンドを使用してファイルの作成、名前変更、削除などを行う場合、FILE_NOTIFY_INFORMATION にはコマンド ラインで指定されたファイル名が含まれます。

これで、ほとんどの場合、GetLongPathName() とその仲間を使用して、使用する一意のパスを取得できました。残念ながら、ファイルを削除するときにはそれを行うことはできません。通知を受け取るまでに、ファイルはすでに削除されており、Get*PathName() 関数は機能しません。

現時点では、より広範なキャッシュを使用して、アプリケーションが各ファイルに使用する代替パス名を決定することを考えています。 . そして、親ディレクトリの変更イベントからの創造的なデータ マイニングと、その場合の実際のディレクトリのチェックにフォールバックすることを考えています。

これを行うためのより簡単な方法について何か提案はありますか?

PS1: Change Journal はこれを効果的に処理しますが (願わくば)、NTFS との関係とアプリケーションの管理者権限がないため、使用できるとは思いません。絶対にやむを得ない場合を除いて、私はむしろそこに行きたくありません。

PS2: 主に Unix でコーディングしていることを覚えておいてください。

ReadDirectoryChangesWAPIe:\testを使用してディレクトリを監視しようとしています。

私のコード：

LPOVERLAPPED ReadDirectoryChangesWのドキュメント、特にパラメータを完全に理解していないため、コードの何が問題になっているのかわかりません。

コードを実行すると、空白のコンソールウィンドウを除いて、何も出力されません。誰かが私を正しい方向に向けることができますか？

ありがとう。

ReadDirectoryChanges Windows API は、ファイル/フォルダー移動イベントを提供しません (ただし、名前変更イベントでは機能します)。代わりに、削除および追加されたイベントを提供します。これを実際の削除および追加イベントとどのように区別しますか。

編集:フォルダがドライブ内で移動しても変更されない Windows のフォルダ固有のプロパティはありますか?.

おっしゃる通り、ReadDirectoryChangesWIO Completion で非同期を試みていますが、うまくいきません。具体的には、GetLastError繰り返し 258 (GetQueuedCompletionStatusタイムアウト) を返します。

私は構造体を持っています:

関連情報を保存するため。これは初期化されます:

次に、ディレクトリ ハンドルと COM ポートを作成します。

次に、この情報を d 経由で新しいスレッドに渡します。今、私が持っている新しいスレッドで：

したがって、これを実行しないように設定すると、ディレクトリが変更されていないため、タイムアウト (258 エラー) が発生します。ただし、ディレクトリを変更してもエラー メッセージが表示されます。つまり、これらの変更は検出されません。これにより、この設定が間違っていると思われます。

何か案は？

警告:

• 皮肉なことに、これは最終的に pywin32 経由で Python に変換されます。ただし、これが C でどのように機能するかを理解するまでは、そこには行きません。
• 同期ReadDirectoryChangesWはオプションではありません。イベントが発生しない場合は、スレッドがまだ実行されているかどうかを確認できるように、タイムアウトするスレッドが必要です。
• 私はC++ではなく、特にCで書いています。
• FindFirstChangeNotificationなどもオプションではありません - ディレクトリの一覧を継続的に比較して、何が変更されたかを調べたくありません。

その他の注意事項:

• ディレクトリが存在します。そのハンドルは NULL ではありません。コンポートハンドルも同様です。
• すべてがスレッドに渡されます

私はコード プロジェクトからCDirectoryChangeWatcherを見てきましたが、C++ の使用とその他の多くのスレッドは別として、自分が何をしているのかわかりません。私が何かを見逃している場合は、遠慮なく指摘してください！

問題のディレクトリをどれだけ変更しても、出力が役立つ場合は、基本的に繰り返されます。

ReadDirectoryChangesWフォルダ内のファイルが追加または削除されたときに通知するために使用するスレッドがあります。

新しい画像ごとに、ファイルを開いて画像のサムネイルを作成します。ただし、ファイルが宛先フォルダーに完全にコピーされる前に通知を受け取ったように見えます。その場合、サムネイルの一部しか表示されません。（ファイルはリモートロケーションから中央サーバーにコピーされ、ネットワークはピーク時に遅くなる可能性があります。）

ファイルが使用されているかどうかを確認しますが、画像ファイルでは機能しないようです。

私の質問はこれです：ファイルが完全にコピーされたことを検出する方法はありますか、それとも最後にチェックしたときからファイルサイズまたは最終変更時刻が変更されなくなるまで待つだけですか？

ReadDirectoryChangesW APIを使用して、Pythonを使用したWindowsでの作成/削除/名前の変更についてディレクトリを監視しようとしています。これは私のコードであり、正常に機能しています。

ただし、監視対象のフォルダーをPythonまたはWindowsエクスプローラーから削除しようとすると、次のようになります。

WindowsError：[エラー32]ファイルが別のプロセスによって使用されているため、プロセスはファイルにアクセスできません：'c：\ users \ user \ appdata \ local \ temp \ new_dir'

これは理にかなっていると思いますが、どうすれば解決できますか？私のアプリケーションでは、ユーザーが監視フォルダーを削除できるようにする必要があるためです。非同期メソッドhttp://www.themacaque.com/?p=859の解決策を試しましたが、役に立ちませんでした。

前もって感謝します！

以下は、 を使用する最小限のプログラムReadDirectoryChangesWです。私が抱えている問題は、最初の呼び出しだけがGetQueuedCompletionStatus返されることです。2 回目のループでは、ディレクトリに何回変更が加えられても、永久にブロックされます。

私も同期バージョンを使用しようとしましたが、まったく同じ問題があります。