Inotify peut-il être utilisé pour surveiller la création d'un fichier spécifique sans surveiller l'intégralité du répertoire?

Je souhaite être averti lorsqu'un nom de fichier spécifique est créé. Je regarde inotify. L' IN_CREATEindicateur est disponible pour surveiller un répertoire pour toutes les modifications qu'il contient, mais je préfère ne pas surveiller le répertoire entier car il peut y avoir beaucoup d'activité dans ce répertoire en plus du fichier qui m'intéresse. ?

linux inotify

— BobDoolittle
source

Je suppose que la réponse est «non». Du moins pas avec inotify. Si vous pouvez contrôler l'emplacement du fichier, vous feriez mieux de créer un répertoire spécial juste pour lui, de sorte que vous pouvez surveiller le répertoire sans être réveillé par des distractions. Si vous ne pouvez pas contrôler l'emplacement, vous devez soit comparer le champ 'nom' retourné avec le nom (relatif) de votre fichier, soit appeler quelque chose comme accessavec F_OKpour voir s'il existe encore.

— BobDoolittle

Vous ne pouvez pas faire en sorte que le noyau vous informe uniquement d'une modification d'un certain chemin. Les raisons sont un peu subtiles:

Sous Linux, un objet fichier existe indépendamment de tout nom qu'il peut avoir. Les noms de fichiers sont en fait des attributs de leur répertoire contenant, et un seul fichier peut être appelé par plusieurs noms (voir, hardlinking).
Le noyau doit avoir quelque chose auquel attacher des objets inotify; il ne peut pas attacher un objet à un nom de chemin car un nom de chemin n'est pas un véritable objet de système de fichiers; vous devez attacher au répertoire parent ou au fichier que le chemin décrit. Mais vous ne pouvez pas attacher au fichier, car vous regardez pour voir si un fichier avec un nom donné est créé, et non des modifications apportées à un fichier donné.

Théoriquement, le noyau pourrait implémenter une API qui vous permet de sélectionner des événements pour un chemin d'accès donné lors de l'ajout d'une surveillance à un répertoire, de la même manière qu'il vous permet de sélectionner des types d'événements. Cela alourdirait l'API, et le noyau finirait par traiter les mêmes données et faire la même comparaison de chaînes que vous feriez dans l'espace utilisateur.

Y a-t-il un impact notable sur les performances en plaçant une montre sur un répertoire très actif? Je ne sais pas à quel point vous voulez dire actif; des dizaines de fichiers par seconde, des centaines, des millions?

En tout cas, accessj'éviterais: ça va toujours être racé. Un fichier pourrait être créé et supprimé entre les appels à access, et appeler accessdans une boucle très serrée va être lent, et c'est le genre de problème qui a inotifyété conçu pour résoudre.

— Dylan Frese
source

Si je ne peux pas être informé d'un "changement dans un certain chemin", comment fonctionne inotify? Faites-vous peut-être référence aux chemins de fichiers en particulier, mais pas aux chemins de répertoire?

— BobDoolittle

De plus, l'avantage d'effectuer la vérification dans le noyau plutôt que dans l'espace utilisateur est qu'il existe plusieurs processus surveillant le répertoire. Au lieu de les changer de contexte inutilement et de les faire tous comparer, vous pouvez simplement basculer dans le processus qui se soucie réellement du chemin d'accès au fichier en question.

— BobDoolittle

Je voulais dire que lors de la surveillance d'un répertoire (qui est évidemment donné par un chemin), vous ne pouvez pas dire au noyau de ne sélectionner que les événements avec un nom donné (alors oui, je fais référence aux chemins de «fichier»). Je comprends les avantages théoriques de ne pas réveiller un tas de processus, mais je dois à nouveau vous demander si vous avez essayé d'utiliser inotifyet si les performances étaient un problème réel.

— Dylan Frese

Alternativement, si de nombreux processus sont intéressés par certains événements, vous pouvez avoir un processus qui surveille les noms de fichiers et envoie des événements `` intéressants '' sur quelque chose comme un socket UNIX aux processus réellement intéressés par ces événements (comme une sorte de service).

— Dylan Frese

Les problèmes de performances peuvent être extrêmement difficiles à mesurer et à diagnostiquer. Plutôt que de marcher dans des murs de briques, je préfère adopter de bonnes pratiques de programmation en premier lieu, développer des logiciels qui utilisent de bons modèles de conception et éviter de telles situations. Donc non, je n'ai pas observé de problème. J'ai anticipé un problème potentiel et évité d'utiliser inotify dans ce cas en raison de problèmes potentiels en cours de route. En tant que développeur de logiciels système, je crois qu'il est important de fournir des mécanismes robustes pour aider les gens à éviter les problèmes de performances, ce qui est le but d'inotify.

— BobDoolittle