inotify nécessite le soutien du noyau au travail. Lorsqu'une application suit un répertoire, elle demande au noyau de l'informer quand ces changements se produisent. Lorsque la modification se produit, en plus d'écrire ces modifications sur le disque, le noyau notifie également le processus de surveillance.
Sur une machine NFS distante, la modification n'est pas visible pour le noyau; cela arrive entièrement à distance. NFS est antérieur à inotify et il n'y a pas de support au niveau réseau dans NFS, ou quoi que ce soit d'équivalent. Si vous voulez contourner cela, vous pouvez exécuter un service sur le serveur de stockage (puisque ce noyau verra toujours les changements au système de fichiers) qui brokers inotify demandes pour les machines distantes, et transmettre les données aux clients distants.
Modifier: Il me semble étrange que NFS soit blâmé pour son manque de support pour inotify.
système de fichiers réseau (NFS) est un protocole de système de fichiers distribué initialement développé par Sun Microsystems en 1984, wikipedia article
Cependant:
Inotify (inode notification) est un Sous-système de noyau Linux qui agit pour étendre les systèmes de fichiers afin de remarquer les modifications apportées au système de fichiers. [...] Il a été inclus dans le noyau Linux principal à partir de la version 2.6.13 (18 juin) [...]. wikipedia article
Il est difficile d'attendre un protocole de réseau portable/application pour soutenir une fonction spécifique du noyau développé pour un autre système d'exploitation et qui est apparu plus de vingt ans plus tard. Même si incluait inclure des extensions, il ne serait pas disponible ou utile sur d'autres systèmes d'exploitation.
* Souligné par l'auteur dans tous les cas
Un autre problème avec cela; Supposons que nous n'utilisons pas du tout un réseau, mais plutôt un système de fichiers local avec un bon support inotify: ext3 (supposons qu'il soit monté à /mnt/foo). Mais au lieu d'un vrai disque, le système de fichiers est monté à partir d'un périphérique de bouclage; et le fichier sous-jacent est à son tour accessible à un emplacement différent dans le vfs (par exemple, /var/images/foo.img). Maintenant, vous n'êtes pas censé modifier les systèmes de fichiers ext3 montés, mais il est toujours raisonnablement sûr de le faire si le changement concerne le contenu des fichiers au lieu des métadonnées. Supposons donc qu'un utilisateur intelligent modifie l'image du système de fichiers (/var/images/foo.img) dans un éditeur hexadécimal, en remplaçant le contenu d'un fichier par d'autres données, tandis qu'une montre inotify observe le même fichier sur le système de fichiers monté.
Il n'y a pas de façon raisonnable de faire en sorte qu'inotify informe toujours le processus de surveillance de ce genre de changement. Bien qu'il y ait probablement quelques changements qui pourraient être pris pour rendre compte du changement et en tenir compte, rien de tout cela ne s'appliquerait, disons, au xfs drtiver, qui est par ailleurs assez similaire.
Il ne devrait pas non plus. Vous trichez!. inotify ne peut vous informer que des modifications survenues via vfs sur le point de montage réel surveillé. Si les changements se sont produits en dehors de ce VFS, en raison d'une modification des données sous-jacentes, inotify ne peut pas vous aider et n'est pas conçu pour résoudre ce problème.
Avez-vous envisagé d'utiliser une file d'attente de messages pour la notification réseau?
Ainsi, vous dites que seul le script sur le serveur qui possède le système de fichiers ou l'ordinateur qui a effectué la modification est averti? C'est le comportement que je m'attendrais. – Gabe
J'ai signalé une demande de fonctionnalité [ici] (https://bugzilla.kernel.org/show_bug.cgi?id=53161). – HRJ