Esto se debe a la forma en que está utilizando inotifywatch
y a la forma en que funciona la herramienta. Cuando corres inotifywatch -r /tmp
, comienzas a mirar /tmp
y todos los archivos que ya están en él. Cuando crea un archivo en el interior /tmp
, los metadatos del directorio se actualizan para contener el número de inodo del nuevo archivo, lo que significa que el cambio ocurre /tmp
, no /tmp/test-1
. Además, dado que /tmp/test-1
no estaba allí cuando inotifywatch
comenzó, no hay ningún inotify
reloj puesto en él. Significa que no se detectará ningún evento que ocurra en un archivo creado después de colocar los relojes . Puede entenderlo mejor si lo ve usted mismo:
$ inotifywatch -rv /tmp &
Total of n watches.
$ cat /sys/kernel/debug/tracing/trace | grep inotifywatch | wc -l
n
Si ha activado el mecanismo de rastreoinotify_add_watch(2)
, el último comando le dará la cantidad de relojes configurados por inotifywatch
. Este número debe ser el mismo que el dado por inotifywatch
sí mismo. Ahora, cree un archivo dentro /tmp
y verifique nuevamente:
$ inotifywatch -rv /tmp &
Total of n watches.
$ touch /tmp/test1.txt
$ cat /sys/kernel/debug/tracing/trace | grep inotifywatch | wc -l
n
El número no habrá aumentado, lo que significa que el nuevo archivo no se ve. Tenga en cuenta que el comportamiento es diferente si crea un directorio en su lugar:
$ inotifywatch -rv /tmp &
Total of n watches.
$ mkdir /tmp/test1
$ cat /sys/kernel/debug/tracing/trace | grep inotifywatch | wc -l
n + 1
Esto se debe a la forma en que -r
se comporta el interruptor :
-r
, --recursive
: [...] Si se crean nuevos directorios dentro de directorios vigilados, se verán automáticamente.
Editar: Tengo un poco confundido entre sus dos ejemplos, pero en el primer caso , los relojes se colocan correctamente debido a las llamadas de los usuarios inotifywatch
sobre ~/*
(que se expande, ver el comentario de don_crissti aquí ). El directorio de inicio también se mira porque ~/.*
contiene ~/.
. Teóricamente, también debería contener ~/..
, lo que, combinado con el -r
interruptor, debería dar como resultado la observación de todo el sistema.
Sin embargo, es posible obtener el nombre del archivo que desencadena un evento de creación en un directorio observado, pero supongo inotifywatch
que no recupera esta información (se guarda un poco más profundo que el nombre del directorio). inotify-tools
proporciona otra herramienta, llamada inotifywait
, que puede comportarse más o menos como inotify-watch
, y proporciona más opciones de salida (incluido %f
, que es lo que está buscando aquí):
inotifywait -m --format "%e %f" /tmp
Desde la página del manual :
--format <fmt>
Salida en un formato especificado por el usuario, utilizando sintaxis similar a printf. [...] Se admiten las siguientes conversiones:
%f
: cuando ocurre un evento dentro de un directorio, este será reemplazado con el nombre del archivo que causó el evento .
%e
: reemplazado por los eventos que ocurrieron, separados por comas.
Además, la -m
opción (monitor) seguirá inotifywait
ejecutándose después del primer evento, lo que reproducirá un comportamiento bastante similar al de inotifywatch
's.
.bashrc
en el ejemplo, @serverfault
no aparece en las estadísticas porque el usuario monitorea su directorio de inicio de forma recursiva, sino porquepath/.*
se expande y, como resultado, se establece un reloj para todos los archivos.path/
(.bashrc
incluidos). El comando utilizado por el OP nunca generará nombres de archivo porque los relojes están configurados/tmp
y cualquier subdirectorio, por lo tanto, las estadísticas solo pertenecen a/tmp
sus subdirectorios (es decir, verá que se ha accedido / movido / etc a los archivos, pero no le dirá su nombres).