Cela est dû à la façon dont vous utilisez inotifywatch
et au fonctionnement de l'outil lui-même. Lorsque vous exécutez inotifywatch -r /tmp
, vous commencez à regarder /tmp
et tous les fichiers qui s'y trouvent déjà . Lorsque vous créez un fichier à l'intérieur /tmp
, les métadonnées du répertoire sont mises à jour pour contenir le numéro d'inode du nouveau fichier, ce qui signifie que la modification se produit /tmp
, non /tmp/test-1
. De plus, comme il /tmp/test-1
n'était pas là au inotifywatch
démarrage, aucune inotify
montre n'est placée dessus. Cela signifie que tout événement qui se produit sur un fichier créé après le placement des montres ne sera pas détecté . Vous le comprendrez peut-être mieux si vous le voyez vous-même:
$ inotifywatch -rv /tmp &
Total of n watches.
$ cat /sys/kernel/debug/tracing/trace | grep inotifywatch | wc -l
n
Si vous avez activé le mécanisme de traçageinotify_add_watch(2)
, la dernière commande vous donnera le nombre de surveillances configurées par inotifywatch
. Ce numéro doit être le même que celui donné par inotifywatch
lui-même. Maintenant, créez un fichier à l'intérieur /tmp
et vérifiez à nouveau:
$ inotifywatch -rv /tmp &
Total of n watches.
$ touch /tmp/test1.txt
$ cat /sys/kernel/debug/tracing/trace | grep inotifywatch | wc -l
n
Le nombre n'aura pas augmenté, ce qui signifie que le nouveau fichier n'est pas surveillé. Notez que le comportement est différent si vous créez un répertoire à la place:
$ inotifywatch -rv /tmp &
Total of n watches.
$ mkdir /tmp/test1
$ cat /sys/kernel/debug/tracing/trace | grep inotifywatch | wc -l
n + 1
Cela est dû à la façon dont le -r
commutateur se comporte :
-r
, --recursive
: [...] Si de nouveaux répertoires sont créés dans des répertoires surveillés, ils seront automatiquement surveillés.
Edit: Je suis un peu confus entre vos deux exemples, mais dans le premier cas , les montres sont correctement placé parce que les appels des utilisateurs inotifywatch
sur ~/*
(qui est expansées, voir le commentaire de don_crissti ici ). Le répertoire personnel est également surveillé car ~/.*
contient ~/.
. Théoriquement, il devrait également contenir ~/..
, ce qui, combiné au -r
commutateur, devrait conduire à surveiller l'ensemble du système.
Cependant, il est possible d'obtenir le nom du fichier déclenchant un événement de création dans un répertoire surveillé, mais je suppose inotifywatch
que ne récupère pas ces informations (il est enregistré un peu plus profondément que le nom du répertoire). inotify-tools
fournit un autre outil, appelé inotifywait
, qui peut se comporter à peu près comme inotify-watch
, et fournit plus d'options de sortie (y compris %f
, ce que vous recherchez ici):
inotifywait -m --format "%e %f" /tmp
Depuis la page de manuel :
--format <fmt>
Sortie dans un format spécifié par l'utilisateur, utilisant une syntaxe semblable à printf. [...] Les conversions suivantes sont prises en charge:
%f
: lorsqu'un événement se produit dans un répertoire, il sera remplacé par le nom du fichier qui a provoqué l'événement .
%e
: remplacé par le ou les événements qui se sont produits, séparés par des virgules.
De plus, l' -m
option (moniteur) continuera de inotifywait
fonctionner après le premier événement, ce qui reproduira un comportement assez similaire à celui inotifywatch
de.
.bashrc
dans l'exemple, @serverfault
n'apparaît pas dans les statistiques parce que l'utilisateur surveille son répertoire personnel de manière récursive mais parce qu'ilpath/.*
est développé et en conséquence une surveillance est définie pour tous les fichiers souspath/
(.bashrc
inclus). La commande utilisée par l'OP ne sortira jamais les noms de fichiers car les surveillances sont définies pour/tmp
et tous les sous-répertoires, donc les statistiques ne concerneront que/tmp
ses sous-répertoires (c'est-à-dire que vous verrez que les fichiers ont été accédés / déplacés / etc mais ils ne vous diront pas leur des noms).