これはinotifywatch、使用している方法と、ツール自体の動作方法によるものです。を実行するとinotifywatch -r /tmp、視聴を開始/tmpし、既にその中にあるすべてのファイルを見ることができます。内部/tmpにファイルを作成すると、ディレクトリメタデータが更新され、新しいファイルのiノード番号が含まれます。つまり、変更は/tmpでなくで行われ/tmp/test-1ます。また、以降の/tmp/test-1時にはなかったinotifywatch始め、何もありませんinotify、それの上に置かれ、時計が。これは、ウォッチが配置された後に作成されたファイルで発生するイベントが検出されないことを意味します。あなたはそれを自分で見ればよりよく理解するかもしれません:
$ inotifywatch -rv /tmp &
Total of n watches.
$ cat /sys/kernel/debug/tracing/trace | grep inotifywatch | wc -l
n
トレースメカニズムinotify_add_watch(2)を有効にした場合、最後のコマンドはによって設定されたウォッチの数を示しますinotifywatch。この番号は、inotifywatchそれ自体で指定された番号と同じでなければなりません。次に、内部にファイルを作成し、/tmp再度確認します。
$ inotifywatch -rv /tmp &
Total of n watches.
$ touch /tmp/test1.txt
$ cat /sys/kernel/debug/tracing/trace | grep inotifywatch | wc -l
n
数は増えません。つまり、新しいファイルは監視されません。代わりにディレクトリを作成する場合、動作が異なることに注意してください。
$ inotifywatch -rv /tmp &
Total of n watches.
$ mkdir /tmp/test1
$ cat /sys/kernel/debug/tracing/trace | grep inotifywatch | wc -l
n + 1
これは、-rスイッチの動作方法によるものです。
-r、--recursive:[...]監視対象ディレクトリ内に新しいディレクトリが作成された場合、それらは自動的に監視されます。
編集:私はあなたの二つの例の間で混乱少しを得たが、最初のケースでユーザー・コールので、時計が正しく配置されているinotifywatch上~/*(拡張され、ここでdon_crisstiさんのコメントを参照してください)。~/.*が含まれているため、ホームディレクトリも監視されます~/.。理論的に~/..は、-rスイッチと組み合わせてシステム全体を監視する必要があるを含む必要があります。
ただし、監視ディレクトリで作成イベントをトリガーするファイルの名前を取得することはできますが、この情報は取得されません(ディレクトリ名よりも少し深い場所に保存されます)。と呼ばれる別のツールを提供します。これは、とほぼ同様に動作し、より多くの出力オプションを提供します(ここで探しているものを含む)。inotifywatchinotify-toolsinotifywaitinotify-watch%f
inotifywait -m --format "%e %f" /tmp
manページから:
--format <fmt>printfに似た構文を使用して、ユーザー指定の形式で出力します。[...]次の変換がサポートされています。
%f:ディレクトリ内でイベントが発生すると、イベントを発生させたファイルの名前に置き換えられます。
%e:発生したイベントにコンマ区切りで置き換えられます。
また、-mオプション(モニター)はinotifywait、最初のイベントの後も実行を続けます。これにより、に非常によく似た動作が再現されinotifywatchます。
.bashrcこの例ではserverfault、ユーザーがホームディレクトリを再帰的に監視するために@ が統計に表示されませんが、path/.*展開されるため、結果としてpath/(.bashrc含まれる)すべての.fileに監視が設定されます。OPが使用するコマンドはファイル名を出力しません。これは、監視が/tmpサブディレクトリに設定されているため、統計は/tmpサブディレクトリとそのサブディレクトリのみに関連するためです(つまり、ファイルにアクセス/移動/などが表示されますが、名前)。