7

私はここで例を微調整して、ファイルの「変更」を繰り返し監視するようにしています。私のコードはここにあります。私のテストでは、inotify通知は、ファイルが「変更された」（つまりtouch「編集された」）ときにのみ発生します。その後のファイルへの変更によって、通知が発生することはありません。stat'Modify'時間が変更されたことを示します。また、コードを変更してウォッチを削除し、通知が発生するたびに再追加する（つまり、移動inotify_add_watchしてサンプルのループinotify_rm_watch内に入れる）ことは、この問題の解決に役立ちませんでした。while(1)

ここの誰かが私が間違っているかもしれないことを助けることができるかどうか疑問に思いました。また、の時計を追加しましたがIN_ALL_EVENTS、本当に気になるのはIN_MODIFYイベントだけです。それが違いを生むかどうかはわかりません。

また、このユースケースは機能しませんか？代わりにディレクトリを監視するようにアプローチを変更する必要がありますか？ご意見をお聞かせください。

TIA。

編集1：themelが指摘したように、処理にiはいくつかの修正が必要でした。ただし、修正バージョンでさえ、後続のファイルシステムの「イベント」に対して通知を発行していません。また、ファイルではなくディレクトリにウォッチを追加すると、同様の非決定論的な動作が見られます。

編集2：この回答に基づいてこのasio+inotifyの例を機能させたいと思います。残念ながら、その例は私にはまったく機能していません。どんな助けでも大歓迎です。TIA。

4

3 に答える 3

7

私のテストでは、themelの修正後、ディレクトリを監視しているときにコードは正常に機能します。ファイルを監視しているとき、event->lenはゼロであり、コードは通知を無視します。

printfステートメントでテストがevent->len削除され、すべてevent->nameが置き換えられたfile_pathため、ファイルを監視する場合にも正常に機能します。

PS：あなたが言及していることに気づきましたtouch。

touch次のイベントを送信します。

IN_OPEN
IN_ATTRIB
IN_CLOSE_WRITE

IN_MODIFYなし

また、今行ったように編集して変更をテストしないでくださいvim。作業コピーとスワップをシャッフルしながらファイルが削除され、時計が削除されます。pico動作します。

于 2013-03-06T02:21:55.153 に答える
3

の処理iが壊れています。ループで0にリセットすることはありません。これにより、後のinotifyイベントは、それらがそれらの前の最長のイベントよりも長い場合にのみ考慮されます。これは、おそらくあなたが望むものではありません。

修正バージョン。

于 2013-03-05T18:24:59.977 に答える
1

個々のファイルを監視する場合、ファイル名が返されないため、event->lenは0になります。多くのサンプルプログラムにこの問題があることに気づきました。

于 2013-12-06T21:25:22.143 に答える