FileSystemWatchers multiples pour surveiller les fichiers sur le système local?

Question

Nous sommes en train d'écrire un outil de type éditeur de texte pour notre système de progiciel de comptabilité interne qui a des actions qui peuvent être effectuées par nos propres spécifications de langage Xml. Ces commandes de macro sont spécifiées dans des fichiers XML et nous avons besoin de la possibilité de contrôler si les fichiers ouverts ont été modifiés en externe.

Le seul problème est qu'il y a peut-être 20-30 fichiers avec des chemins différents ouverts à la fois. Serait-il bon d'utiliser plusieurs FileSystemWatchers pour ce scénario? Ou serait-il préférable de surveiller le lecteur racine et d'attraper des événements spécifiques qui correspondent à un fichier ouvert dans l'éditeur (bien que de nombreux événements pourraient être soulevés).

Certains sont des lecteurs locaux (C, D, E), d'autres sont leurs lecteurs réseau (U, X, G, H). Les fichiers sont assez volumineux aussi environ 300-400Kb.

Answer 1

Je pense que vous auriez certainement besoin de plusieurs observateurs. Le tampon FileSystemWatcher peut déborder et vous risquez de manquer des événements, sinon vous pouvez changer la taille de la mémoire tampon (en utilisant InternalBufferSize) mais seulement 64 Ko. Cependant, sachez que FileSystemWatcher utilise FindFirstChangeNotification, ce qui n'est pas totalement fiable pour les lecteurs en réseau (surtout si vous êtes sous une charge importante, mais peut-être aussi), vous devez donc prévoir et planifier que vous ne recevrez pas tous les événements du réseau, et ma compréhension est que la fiabilité devient encore pire si vous avez plusieurs observateurs. Donc, en résumé, je pense que vous devrez augmenter les tampons, filtrer autant que possible et utiliser le moins de surveillance possible sans déborder les tampons, donc il faudra probablement faire un peu d'essais et d'erreurs pour bien faire les choses.

Answer 2

D'abord quelques faits

1- FileSystemWatcher est un wrapper autour ReadDirectoryChanges
2- ReadDirectoryChanges crée un tampon Kernal en cache événement à partir de la mémoire non paginée pour chaque appel à ReadDirectoryChanges

Le L'implication du point 2 ci-dessus est que chaque instance de FileSystemWatcher allouera de la mémoire à partir du pool non paginé. Gardez à l'esprit qu'il s'agit de la mémoire utilisée pour les pilotes en mode noyau, et bien qu'elle puisse être étendue dynamiquement, elle est "limitée" à une taille maximale calculée au démarrage en fonction des ressources de votre système (quantité de mémoire).

Compte tenu de ce qui précède, je considérerais ce qui suit.

Si le volume de modifications que vous vous attendez à voir. Si cela est faible, optez pour plusieurs observateurs avec la plus petite taille de mémoire tampon que vous pouvez obtenir. Gardez à l'esprit que si vous décidez d'opter pour des buffers volumineux, la surveillance des disques réseau ne prend pas en charge les tailles de buffer supérieures à 64 Ko, plus grandes que cela et vous n'obtiendrez pas les événements.