Discussion :

[Daramor]

Je m'explique mieux : j'ai une application (que je ne contrôle pas) qui écrit dans un fichier de log (texte ASCII). Je dois réaliser un moniteur qui permette de lire les lignes au moment de leur écriture pour détecter certains événements et envoyer une alerte.
Le fichier de log n'est jamais purgé lors de la session, il peut avoir une taille allant jusqu'à 20Mo. Le programme serveur peut fournir jusqu'à une cinquantaine de lignes à la seconde.
Quelle stratégie et quels objets devrais-je utiliser pour ce genre d'application ? J'ai déjà fait des tentatives avec le FileSystemWatcher, mais celui-ci ne semble pas se déclencher sur une écriture du serveur dans le fichier.

[Mehdi Feki]

FileSystemWatcher est le meilleur solution dans ton cas.

Le système d'exploitation Windows notifie votre composant de modifications apportées aux fichiers dans une mémoire tampon créée par FileSystemWatcher. Si plusieurs modifications sont apportées en un court laps de temps, la mémoire tampon risque de déborder. Le composant risque alors de perdre la trace des modifications apportées au répertoire et ne donnera qu'une notification standard. L'augmentation de la taille de la mémoire tampon par le biais de la propriété InternalBufferSize est coûteuse car elle provient d'une mémoire non paginée ne pouvant pas être transférée sur le disque. Ne saturez donc pas la mémoire tampon et veillez à ce qu'elle soit suffisamment grande pour ne manquer aucun événement de modification de fichier. Pour éviter une saturation de la mémoire tampon, utilisez les propriétés NotifyFilter et IncludeSubdirectories pour filtrer les notifications de modifications inutiles.

Essai d'utiliser les filtres

[Mose]

Euh.. tu risques pas d'avoir des soucis à ouvrir un fichier qui se fait ouvrir 50 fois par secondes ?

[Daramor]

Mehdi : Apparemment, le FileSystemWatcher ne déclenche d'événement sur la taille du fichier que si on franchit une limite de 4k dans le stockage.

Mose : D'autres ont déjà résolu ce problème il semble, car il existe d'autres parsers pour le même genre de fichiers, qui travaillent bien en temps réel, mais dont je ne connais pas les sources. 50 lignes/seconde est sans doute l'un des cas extrêmes, le débit va de une ligne toutes les quelques secondes à une vingtaine de lignes par seconde normalement. D'autres programmes analysent ce flux en temps réel, mais ne correspondent pas à mes besoins spécifiques.

C'est vrai que je ne connais pas réellement la manière dont cela est effectué.
Ce qui est sûr c'est que je peux effacer le fichier de log en cours d'utilisation par l'explorateur Windows, donc je suppose que cela signifie obligatoirement que le programme qui crée le log referme le fichier et ne se contente pas de faire un flush. Confirmation quelqu'un ?

Mais la piste soulevée par Mose est intéressante, s'il suffit de :
- vérifier la taille exacte du fichier
- si elle n'a pas changé, ne rien faire (attente)
- sinon :
-ouvrir le fichier,
-se positionner à la "fin" précédente,
-lire les lignes qui suivent (les parser)
-mémoriser la nouvelle longueur

Je vais essayer cette voie.

[Mose]

Ce qui est sûr c'est que je peux effacer le fichier de log en cours d'utilisation par l'explorateur Windows, donc je suppose que cela signifie obligatoirement que le programme qui crée le log referme le fichier et ne se contente pas de faire un flush. Confirmation quelqu'un ?

Ah vi vi vi, c'est bon signe...

En revanche, perso j'ouvrirais le fichier, je le lirais intégralement (StreamReader.ReadToEnd()) et je bosserais là dessus pour minimizer les possibilités de conflit.
Sinon, pour savoir si le fichier viens d'être modifier, c'est bien FileSystemWatcher. Jamais utilisé perso. Y'a pas moyen de le configurer pour qu'il déclenche l'évènement plus tôt ?

[Daramor]

J'ai progressé sur le sujet, et repris le projet en C normal, que je connais mieux. Le code suivant fonctionne :

void lire()
{
FILE* stream;
char line[100];

if ((stream = fopen("data.txt", "r")) == NULL) return;
fseek(stream,0,SEEK_END);
while (1)
{
line[0] = 0;
fgets(line, 100, stream);
printf ("%s", line); // ici on peut interpréter la ligne à la place
}
fclose (stream); // bon, on n'arrive jamais ici avec la boucle infinie ci-dessous
}

Maintenant finalement mon problème est de l'ordre de la connaissance des classes de C# : comment écrire la même chose en C# ?

[Mose]

File * tu peux le traduire en System.IO.FileStream
- le constructeur remplace le Open
- le fseek c'est devenu Seek
- le fget c'est Read (pitain c'est méchamment ésotérique le C quand on y pense )
- à la fin faut faire un Close

Pour le printf : Console.WriteLine(string)
Pour formater une chaine : String.Format (et là tu consulte la doc pour comprendre le formattage en C# qui est complètement différent)