Cela est dû à la façon dont vous utilisez inotifywatchet au fonctionnement de l'outil lui-même. Lorsque vous exécutez inotifywatch -r /tmp, vous commencez à regarder /tmpet 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-1n'était pas là au inotifywatchdémarrage, aucune inotifymontre 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 inotifywatchlui-même. Maintenant, créez un fichier à l'intérieur /tmpet 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 -rcommutateur 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 inotifywatchsur ~/*(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 -rcommutateur, 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 inotifywatchque ne récupère pas ces informations (il est enregistré un peu plus profondément que le nom du répertoire). inotify-toolsfournit 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' -moption (moniteur) continuera de inotifywaitfonctionner après le premier événement, ce qui reproduira un comportement assez similaire à celui inotifywatchde.
.bashrcdans l'exemple, @serverfaultn'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/(.bashrcinclus). La commande utilisée par l'OP ne sortira jamais les noms de fichiers car les surveillances sont définies pour/tmpet tous les sous-répertoires, donc les statistiques ne concerneront que/tmpses 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).