¿Se puede usar inotify para observar la creación de un archivo específico sin monitorear todo el directorio?

Quiero recibir una notificación cuando se cree un nombre de archivo específico. Estoy mirando inotify. El IN_CREATEindicador está disponible para monitorear un directorio para cualquier cambio dentro de él, pero preferiría no monitorear todo el directorio ya que puede haber mucha actividad en ese directorio además del archivo en el que estoy interesado. ¿Se puede hacer esto? ?

linux inotify

— BobDoolittle
fuente

Supongo que la respuesta es 'no'. Al menos no con inotify. Si puede controlar la ubicación del archivo, es mejor que cree un directorio especial solo para él, de modo que pueda monitorear el directorio sin ser despertado por distracciones. Si no puede controlar la ubicación, se enfrenta a cualquiera de comparar el campo devuelto 'nombre' en contra del nombre (relativa) de su archivo, o llamar a algo que se le parezca accesscon F_OKpara ver si todavía existe.

— BobDoolittle

No puede hacer que el núcleo solo le informe de un cambio en una ruta determinada. Las razones son un poco sutiles:

En Linux, un objeto de archivo existe independientemente de cualquier nombre (s) que pueda tener. Los nombres de los archivos son en realidad atributos de su directorio contenedor, y un solo archivo puede ser llamado por varios nombres (ver, hardlinking).
El núcleo tiene que tener algo para adjuntar objetos inotify; no puede adjuntar un objeto a un nombre de ruta ya que un nombre de ruta no es un objeto real del sistema de archivos; debe adjuntarlo al directorio principal o al archivo que describe la ruta. Pero no puede adjuntarlo al archivo, ya que está observando si se crea un archivo con un nombre determinado, no cambios en un archivo dado.

Teóricamente, el núcleo podría implementar una API que le permita seleccionar eventos para un nombre de ruta dado al agregar un reloj a un directorio, de la misma manera que le permite seleccionar tipos de eventos. Esto hincharía la API, y el núcleo al final estaría procesando los mismos datos y haciendo la misma comparación de cadenas que estaría haciendo en el espacio de usuario.

¿Hay un impacto notable en el rendimiento al colocar un reloj en un directorio muy activo? No estoy seguro de qué tan activo quieres decir; ¿Decenas de archivos por segundo, cientos, millones?

En cualquier caso, evitaría access: siempre va a ser una carrera. Se podría crear y eliminar un archivo entre llamadas a access, y las llamadas accessen un ciclo muy cerrado serán lentas, y es el tipo de problema que inotifyfue diseñado para resolver.

— Dylan Frese
fuente

Si no puedo ser informado de "un cambio en una ruta determinada", ¿cómo funciona la inotificación? ¿Te estás refiriendo específicamente a las rutas de archivo pero no a las rutas de directorio?

— BobDoolittle

Además, la ventaja de hacer la verificación en el kernel en lugar del espacio de usuario es si hay múltiples procesos monitoreando el directorio. En lugar de que el contexto los cambie a todos innecesariamente y haga que todos hagan una comparación, simplemente puede cambiar el proceso que realmente se preocupa por la ruta del archivo en cuestión.

— BobDoolittle

Quise decir que cuando se monitorea un directorio (que obviamente viene dado por una ruta), no se le puede decir al kernel que seleccione solo eventos con un nombre dado (así que sí, me estoy refiriendo a las rutas de 'archivo'). Entiendo los beneficios teóricos de no activar un montón de procesos, pero tengo que volver a preguntarle si intentó usarlo inotifyy si el rendimiento fue un problema real.

— Dylan Frese

Alternativamente, si muchos procesos están interesados en ciertos eventos, puede hacer que un proceso esté atento a los nombres de archivos y envíe eventos 'interesantes' a través de algo así como un socket UNIX a los procesos realmente interesados en estos eventos (como una especie de servicio).

— Dylan Frese

Los problemas de rendimiento pueden ser extremadamente difíciles de medir y diagnosticar. En lugar de caminar hacia paredes de ladrillo, prefiero adoptar buenas prácticas de programación en primer lugar, desarrollar software que use buenos patrones de diseño y evitar tales situaciones. Entonces no, no observé un problema. Anticipé un problema potencial y evité el uso de inotify en este caso debido al potencial de problemas en el futuro. Como desarrollador de software del sistema, creo en proporcionar mecanismos robustos para ayudar a las personas a evitar problemas de rendimiento, que es el propósito de inotify.

— BobDoolittle