Lecture d’événements d’un descripteur de fichier inotify¶

Pour déterminer quels événements ont eu lieu, une application va lire avec read(2) le descripteur de fichier inotify. Si aucun événement n'a eu lieu, alors, en supposant qu'il s'agisse d'un descripteur de fichier bloquant, read(2) se bloquera jusqu'à ce qu'au moins un événement ait lieu (à moins qu'elle ne soit interrompue par un signal, auquel cas l'appel échouera avec l'erreur EINTR ; consultez signal(7)).

Chaque lecture (avec read(2)) réussie renvoie un tampon contenant une ou plusieurs des structures suivantes :

struct inotify_event {


    int      wd;       /* Descripteur de surveillance */


    uint32_t mask;     /* Masque décrivant l’événement */


    uint32_t cookie;   /* Cookie unique d'association des


                          événements (pour rename(2)) */


    uint32_t len;      /* Taille du champ name */


    char     name[];   /* Nom optionnel terminé par un nul */
};

wd identifie l'élément de surveillance pour lequel cet événement a lieu. Il s'agit de l'un des descripteurs de surveillance renvoyés par un précédent appel à inotify_add_watch(2).

mask contient des bits qui décrivent l'événement qui a eu lieu (voir ci-dessous).

cookie est un entier unique qui relie les événements. Ce n'est actuellement utilisé que pour les événements de renommage, et permet à la paire d'événements IN_MOVED_FROM et IN_MOVED_TO en résultant d'être associée par l'application. Pour tous les autres types d'événements, cookie est mis à 0.

The name field is present only when an event is returned for a file inside a watched directory; it identifies the filename within the watched directory. This filename is null-terminated, and may include further null bytes ('\0') to align subsequent reads to a suitable address boundary.

Le champ len compte tous les octets de name, incluant les caractères nuls. La longueur de chaque structure inotify_event vaut donc sizeof(structinotify_event)+len.

The behavior when the buffer given to read(2) is too small to return information about the next event depends on the kernel version: before Linux 2.6.21, read(2) returns 0; since Linux 2.6.21, read(2) fails with the error EINVAL. Specifying a buffer of size

sizeof(struct inotify_event) + NAME_MAX + 1

est suffisant pour lire au moins un événement.

Événements inotify¶

L'argument mask passé à inotify_add_watch(2) et le champ mask de la structure inotify_event renvoyés lors de la lecture avec read(2) d'un descripteur de fichier inotify sont tous deux des masques binaires identifiant les événements inotify. Les bits suivants peuvent être définis dans l'argument mask lors de l'appel à inotify_add_watch(2) et peuvent être renvoyés dans le champ mask renvoyé par read(2).

La surveillance par Inotify est basée sur les inodes : lorsqu'un fichier est surveillé (mais pas lors de la surveillance d'un répertoire contenant un fichier), un événement peut être créé sur tout lien vers le fichier (dans le même répertoire ou dans un répertoire différent).

Lors de la surveillance d'un répertoire :

•

les événements marqués précédemment par un astérisque (*) peuvent avoir lieu à la fois pour le répertoire et pour les objets à l’intérieur du répertoire ;

•

les événements marqués par un signe plus (+) n’ont lieu que pour les objets à l’intérieur du répertoire (et non pour le répertoire lui-même).

Note : lorsqu'un répertoire est surveillé, les événements ne sont pas créés pour les fichiers contenus dans le répertoire quand des événements sont exécutés avec un nom de chemin (par exemple, un lien) qui se trouve hors du répertoire surveillé.

Lorsque les événements sont créés pour les objets dans un répertoire surveillé, le champ name dans la structure inotify_event renvoyée identifie le nom du fichier dans ce répertoire.

La macro IN_ALL_EVENTS est définie comme un masque binaire de tous les événements décrits ci-dessus. Cette macro peut être utilisée comme l'argument mask lors de l'appel à inotify_add_watch(2).

Deux macros supplémentaires de convenance sont définies :

Les bits supplémentaires suivants peuvent être indiqués dans l'argument mask lors de l'appel à inotify_add_watch(2) :

Les bits suivants peuvent avoir été définis dans le champ mask renvoyé par read(2) :

Exemples¶

Soit une application surveillant le répertoire rép et le fichier rép/monfichier pour tous les événements. Les exemples ci-dessous montrent quelques événements qui seront générés pour ces deux objets.

Soit une application surveillant les répertoires rép1 et rép2, et le fichier rép1/monfichier. Les exemples suivants montrent quelques événements qui pourraient être générés.

Soient rép1/xx et rép2/yy les (seuls) liens vers le même ficher, et une application surveillant rép1, rép2, rép1/xx et rép2/yy. L’exécution des appels suivants dans l’ordre donné ci-dessous générera les événements suivants :

Soit une application surveillant le répertoire rép et le répertoire (vide) rép/sousrép. Les exemples suivants montrent quelques événements qui pourraient être générés.

Interfaces /proc¶

Les interfaces suivantes peuvent être utilisées pour limiter la quantité de mémoire du noyau utilisée par inotify :

/proc/sys/fs/inotify/max_queued_events

La valeur dans ce fichier est utilisée lorsqu'une application appelle inotify_init(2) pour définir la limite maximale du nombre des événements qui peuvent entrer dans la file d'attente de l'instance inotify correspondante. Les événements au-delà de cette limite sont annulés, mais un événement IN_Q_OVERFLOW est systématiquement généré.

/proc/sys/fs/inotify/max_user_instances

Cela indique la limite maximale du nombre d'instances inotify qui peuvent être créées par identifiant utilisateur réel.

/proc/sys/fs/inotify/max_user_watches

Cela indique la limite maximale du nombre de « watch » qui peuvent être créés par identifiant utilisateur réel.

Limites et réserves¶

L'interface inotify ne fournit aucun renseignement sur l'utilisateur ou le processus qui a déclenché l'événement inotify. En particulier, un processus en train de surveiller des événements à l'aide d'inotify ne dispose d'aucun moyen facile pour distinguer les événements qu'il déclenche lui-même de ceux qui ont été déclenchés par d'autres processus.

Inotify ne signale que les événements déclenchés par un programme en espace utilisateur à l’aide de l’interface de programmation de système de fichiers. Par conséquent, elle n’intercepte pas les événements qui surviennent sur les systèmes de fichiers en réseau (les applications doivent avoir recours à la scrutation (polling) pour intercepter ce type d’événements). De plus, divers pseudo-systèmes de fichiers comme /proc, /sys et /dev/pts ne sont pas surveillables avec inotify.

L'interface inotify ne signale pas les accès ni les modifications de fichier qui pourraient survenir à cause de mmap(2), msync(2) ou munmap(2).

L'interface inotify identifie les fichiers affectés par leur nom. Cependant, au moment où l'application traite un événement inotify, ce nom de fichier peut avoir déjà été supprimé ou renommé.

L’interface inotify identifie les événements à l’aide de descripteurs de surveillance. L’application est responsable de mettre en cache une correspondance (si nécessaire) entre les descripteurs de fichier et les chemins. Soyez vigilants aux renommages de répertoire qui pourraient affecter plusieurs chemins en cache.

La surveillance inotify des répertoires n'est pas récursive : pour surveiller les sous-répertoires, des éléments de surveillance supplémentaires doivent être créés. Cela peut être assez long pour les répertoires contenant une grande arborescence.

Si la surveillance concerne une arborescence dans son intégralité, et si un nouveau sous-répertoire est créé dans ce répertoire ou si un répertoire existant est renommé dans cette arborescence, soyez conscient qu'au moment où vous créez un élément de surveillance pour le nouveau sous-répertoire, de nouveaux fichiers (et sous-répertoires) peuvent déjà exister dans le sous-répertoire. Ainsi, vous devriez analyser le contenu du sous-répertoire immédiatement après avoir ajouté l'élément de surveillance (et, si nécessaire, ajouter des éléments de surveillance pour tous les sous-répertoires qu’il contient).

Remarquez que la file d'événements peut déborder. Dans ce cas, des événements sont perdus. Les applications robustes devraient gérer correctement la possibilité de perdre des événements. Par exemple, la reconstruction de tout ou partie du cache de l’application pourrait être nécessaire (une approche simple, mais éventuellement coûteuse, est de fermer le descripteur de fichier inotify, vider le cache, créer un nouveau descripteur de fichier inotify et recréer les éléments de surveillance et les entrées du cache pour les objets à surveiller).

Si un système de fichiers est monté par dessus un répertoire surveillé, aucun événement n'est généré, pas plus que pour les objets se trouvant directement sous le nouveau point de montage. Si le système de fichiers est par la suite démonté, les événements seront créés pour le répertoire et les objets qu'il contient.

Traitement des événements rename()¶

Comme noté précédemment, la paire d’événements IN_MOVED_FROM et IN_MOVED_TO générée par rename(2) peut être assemblée à l’aide de la valeur de cookie partagé. Cependant, la tâche d’assemblage peut poser quelques problèmes.

Ces deux événements sont normalement consécutifs dans le flux d’événements disponibles lors de la lecture depuis le descripteur de fichiers inotify. Cependant, ce n’est pas garanti. Si plusieurs processus déclenchent des événements pour des objets surveillés, alors (rarement) un nombre arbitraire d’autres événements pourrait apparaître entre les événements IN_MOVED_FROM et IN_MOVED_TO. De plus, il n'est pas garanti que la paire d'événements soit insérée de façon atomique dans la file : il pourrait y avoir un bref intervalle au cours duquel IN_MOVED_FROM est apparu, mais pas IN_MOVED_TO.

L’assemblage de la paire d’événements IN_MOVED_FROM et IN_MOVED_TO générés par rename(2) pose donc intrinsèquement un risque de situation de compétition (n’oubliez pas que si un objet est renommé en dehors d’un répertoire surveillé, un événement IN_MOVED_TO pourrait ne même pas être envoyé). Des approches heuristiques (par exemple supposer que les événements sont toujours consécutifs) permettent d’assurer un assemblage dans la plupart des cas, mais manqueront forcément certains cas, forçant l’application à percevoir les événements IN_MOVED_FROM et IN_MOVED_TO comme indépendants. Si les descripteurs de surveillance sont détruits et recréés par conséquent, alors ces descripteurs de surveillance seront incohérents avec les descripteurs de surveillance dans tous les événements en attente (la recréation du descripteur de fichier inotify et la reconstruction du cache pourrait être utile dans ce cas).

Applications should also allow for the possibility that the IN_MOVED_FROM event was the last event that could fit in the buffer returned by the current call to read(2), and the accompanying IN_MOVED_TO event might be fetched only on the next read(2), which should be done with a (small) timeout to allow for the fact that insertion of the IN_MOVED_FROM+IN_MOVED_TO event pair is not atomic, and also the possibility that there may not be any IN_MOVED_TO event.

Sortie de l’exemple¶

$ ./a.out /tmp /home/utilisateur/temp
Appuyer sur la touche Entrée pour quitter.
En écoute d’événements.
IN_OPEN : /home/utilisateur/temp/toto [fichier]
IN_CLOSE_WRITE : /home/utilisateur/temp/toto [fichier]
IN_OPEN : /tmp/ [répertoire]
IN_CLOSE_NOWRITE : /tmp/ [répertoire]
Arrêt de l’écoute d’événements.

Source du programme¶

#include <errno.h>
#include <poll.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/inotify.h>
#include <unistd.h>
#include <string.h>
/* Read all available inotify events from the file descriptor 'fd'.


   wd is the table of watch descriptors for the directories in argv.


   argc is the length of wd and argv.


   argv is the list of watched directories.


   Entry 0 of wd and argv is unused. */
static void
handle_events(int fd, int *wd, int argc, char* argv[])
{


    /* Certains systèmes ne peuvent pas lire de variables entières


       si elles ne sont pas alignées correctement. Sur d’autres


       systèmes, un alignement incorrect pourrait diminuer les


       performances. Par conséquent, le tampon utilisé pour lire


       le descripteur de fichier inotify devrait avoir le même


       alignement que struct inotify_event. */


    char buf[4096]


        __attribute__ ((aligned(__alignof__(struct inotify_event))));


    const struct inotify_event *event;


    ssize_t len;


    /* Boucler tant que les événements peuvent être lus à partir du


       descripteur de fichier inotify */


    for (;;) {


        /* Lire certains événements. */


        len = read(fd, buf, sizeof(buf));


        if (len == -1 && errno != EAGAIN) {


            perror("read");


            exit(EXIT_FAILURE);


        }


        /* If the nonblocking read() found no events to read, then


           it returns -1 with errno set to EAGAIN. In that case,


           we exit the loop. */


        if (len <= 0)


            break;


        /* Loop over all events in the buffer. */


        for (char *ptr = buf; ptr < buf + len;


                ptr += sizeof(struct inotify_event) + event->len) {


            event = (const struct inotify_event *) ptr;


            /* Print event type. */


            if (event->mask & IN_OPEN)


                printf("IN_OPEN : ");


            if (event->mask & IN_CLOSE_NOWRITE)


                printf("IN_CLOSE_NOWRITE : ");


            if (event->mask & IN_CLOSE_WRITE)


                printf("IN_CLOSE_WRITE : ");


            /* Print the name of the watched directory. */


            for (size_t i = 1; i < argc; ++i) {


                if (wd[i] == event->wd) {


                    printf("%s/", argv[i]);


                    break;


                }


            }


            /* Print the name of the file. */


            if (event->len)


                printf("%s", event->name);


            /* Print type of filesystem object. */


            if (event->mask & IN_ISDIR)


                printf(" [répertoire]\n");


            else


                printf(" [fichier]\n");


        }


    }
}
int
main(int argc, char* argv[])
{


    char buf;


    int fd, i, poll_num;


    int *wd;


    nfds_t nfds;


    struct pollfd fds[2];


    if (argc < 2) {


        printf("Utilisation : %s CHEMIN [CHEMIN ...]\n", argv[0]);


        exit(EXIT_FAILURE);


    }


    printf("Appuyer sur la touche Entrée pour quitter.\n");


    /* Create the file descriptor for accessing the inotify API. */


    fd = inotify_init1(IN_NONBLOCK);


    if (fd == -1) {


        perror("inotify_init1");


        exit(EXIT_FAILURE);


    }


    /* Allocate memory for watch descriptors. */


    wd = calloc(argc, sizeof(int));


    if (wd == NULL) {


        perror("calloc");


        exit(EXIT_FAILURE);


    }


    /* Marquer les répertoires pour les événements :


       - un fichier a été ouvert ;


       - un fichier a été fermé


    for (i = 1; i < argc; i++) {


        wd[i] = inotify_add_watch(fd, argv[i],


                                  IN_OPEN | IN_CLOSE);


        if (wd[i] == -1) {


            fprintf(stderr, "Cannot watch '%s': %s\n",


                    argv[i], strerror(errno));


            exit(EXIT_FAILURE);


        }


    }


    /* Prepare for polling. */


    nfds = 2;


    fds[0].fd = STDIN_FILENO;       /* Console input */


    fds[0].events = POLLIN;


    fds[1].fd = fd;                 /* Inotify input */


    fds[1].events = POLLIN;


    /* Wait for events and/or terminal input. */


    printf("En écoute d’événements.\n");


    while (1) {


        poll_num = poll(fds, nfds, -1);


        if (poll_num == -1) {


            if (errno == EINTR)


                continue;


            perror("poll");


            exit(EXIT_FAILURE);


        }


        if (poll_num > 0) {


            if (fds[0].revents & POLLIN) {


                /* Console input is available. Empty stdin and quit. */


                while (read(STDIN_FILENO, &buf, 1) > 0 && buf != '\n')


                    continue;


                break;


            }


            if (fds[1].revents & POLLIN) {


                /* Inotify events are available. */


                handle_events(fd, wd, argc, argv);


            }


        }


    }


    printf("Arrêt de l’écoute d’événements.\n");


    /* Close inotify file descriptor. */


    close(fd);


    free(wd);


    exit(EXIT_SUCCESS);
}