Journal Comment surveiller un fichier sous Linux

Posté par  .
Étiquettes : aucune
0
9
nov.
2004
Salut,

Je suis en train de me demande comment implémenter dans un de mes programmes C une routine qui surveille la modif d'un fichier, et force est de constater que le sujet n'est pas évident.

En gros il y a 2 approches majeures : un appel système propre à Linux (voir dnotify.txt dans la source du kernel) et le démon fam qui manifestement ne fait pas l'unanimité.

Voila un lien sympathique qui résume les différentes approches :
http://www.devchannel.org/devtoolschannel/04/05/13/2146252.shtml(...)

J'aurais bien posté une astuce mais ça m'a l'air trop spécifique, et puis il y a un lien extérieur.

Pour le premier exemple (et le deuxième aussi d'ailleurs) l'en-tête a sauté, voila ce qu'il faut rajouter :

#define _GNU_SOURCE
#include < fcntl.h >
#include < linux/sys.h >
#include < stdio.h >
#include < errno.h >
#include < signal.h >
#include < stdlib.h >
#include < string.h >
#include < unistd.h >

Voila voila, ça n'intéressera probablement pas grand monde mais moi ça m'a bien rendu service donc pourquoi pas un autre...

  • # Test

    Posté par  . Évalué à 4.

    J'ai testé les 2 méthodes, la première perd les pédales si le fichier de test est modifié trop souvent. Exemple : j'ai lancé 10 fois de suite un echo >> dans un fichier alors que le programme tournait derrière, il n'a détecté que 4 changements.

    Aucun problème en revanche avec fam. Ca marche nickel. D'ailleurs, il me semble que Nautilus et Konqueror utilisent fam pour détecter la modification d'un fichier. Toutefois, Google m'a gentiment aiguillé vers quelques avis hargneux sur fam...

  • # McCutchan, Robert Love, Inotify

    Posté par  . Évalué à 1.

    FAM n'a jamais ete reelement integre au noyau a ma connaissance. Il s'agit d'un projet SGI... (http://oss.sgi.com/projects/fam(...))

    Dnotify est en passe de se faire remplacer par Inotify (ecrit par McCutchan, moins lourd), voir les postes et les slides de Robert Love (sur sa page) pour les details: http://kerneltrap.org/node/view/3847(...)

    A noter que de nombreux front sont disponibles qui se servent de ses differents mechanismes de maniere transparente. Je pense a efsd par exemple (ayant etudie le source y'a 3 ans), http://www.enlightenment.org/pages/efsd.html(...) ou Gamin, utilise par KDE. Y'a surement un equivalent pour Gnome/Nautilus.

    J'aurais bien rien poste du tout, mais je me suis dit que ca pouvait toujours servir a quelqu'un, un jour, par hasard...

    • [^] # Commentaire supprimé

      Posté par  . Évalué à 2.

      Ce commentaire a été supprimé par l’équipe de modération.

  • # ben ...

    Posté par  (site web personnel) . Évalué à 1.

    man select ?

    • [^] # Re: ben ...

      Posté par  (site web personnel) . Évalué à 3.

      ben non.

    • [^] # Re: ben ...

      Posté par  (site web personnel) . Évalué à 2.

      select, c'est pour surveiller des file descriptors, c'est à dire des fichiers ouverts (le plus souvent). Ca te permet de savoir quand tu peux ecrire ou lire dans un fd, qui n'est pas forcement un fichier (par exemple stdin, stdout). select est un appel système.

      fam, c'est pour surveiller des fichiers (ouverts ou non). Ca ne te permet pas de savoir si tu peux ecrire ou lire. C'est fait pour surveiller le changement d'état des fichiers uniquement (par exemple, changement de la taille du fichier). fam est une lib. Cette lib fonctionne soit en utilisant un appel système (si disponible), soit en lisant régulièrement le système de fichier (toutes les 6 secondes par exemple).

  • # La question est-elle pertinente?

    Posté par  . Évalué à 2.

    Pourquoi surveiller ce fichier? Est-ce qu'il n'y a pas moyen d'obtenir la même fonctionnalité sans surveillance de fichier? (c'est peu portable)

    Snark

  • # Fichiers spéciaux

    Posté par  (site web personnel) . Évalué à 2.

    Est-ce que ça marche avec des fichiers spéciaux (par exemple /proc ou /dev) ?

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.