Je dois mettre en place une application qui surveille la création de fichiers dans un répertoire, à la fois localement et sur un lecteur réseau.
Le FileSystemWatcher ou l'interrogation d'une horloge serait la meilleure option. J'ai utilisé ces deux méthodes dans le passé, mais pas de manière intensive.
Quels sont les problèmes (performance, fiabilité, etc.) posés par l'une ou l'autre méthode ?
J'ai vu l'observateur du système de fichiers échouer dans des environnements de production et de test. Je le considère maintenant comme une commodité, mais je ne le considère pas comme fiable. J'ai pour habitude de surveiller les modifications avec l'observateur du système de fichiers, mais de sonder de temps en temps pour détecter les modifications de fichiers manquants.
Modification : si vous disposez d'une interface utilisateur, vous pouvez également donner à l'utilisateur la possibilité de "rafraîchir" les modifications au lieu d'effectuer des sondages. Je combinerais cela avec un observateur de système de fichiers.
Le plus gros problème que j'ai rencontré est celui des fichiers manquants lorsque la mémoire tampon est pleine. Facile à résoudre, il suffit d'augmenter la mémoire tampon. N'oubliez pas qu'il contient les noms de fichiers et les événements, alors augmentez-le jusqu'au nombre de fichiers attendus (essais et erreurs). Il utilise de la mémoire qui ne peut pas être paginée, il peut donc forcer d'autres processus à paginer si la mémoire devient faible.
Voici l'article de MSDN sur la mémoire tampon : Propriété FileSystemWatcher..: :.InternalBufferSize
Selon MSDN :
L'augmentation de la taille de la mémoire tampon est coûteuse, car elle provient d'une mémoire non paginée qui ne peut pas être transférée sur le disque ; la mémoire tampon doit donc être aussi petite que possible. Pour éviter un débordement de la mémoire tampon, utilisez les propriétés NotifyFilter et IncludeSubdirectories pour filtrer les notifications de changement non souhaitées.
Nous utilisons 16 Mo en raison d'un lot important attendu en une seule fois. Il fonctionne parfaitement et ne manque jamais un fichier.
Nous lisons également tous les fichiers avant de commencer à en traiter un seul... nous mettons les noms de fichiers en cache (dans notre cas, dans une table de la base de données), puis nous les traitons.
Pour les problèmes de verrouillage de fichiers, je lance un processus qui attend que le fichier soit déverrouillé pendant une seconde, puis deux, puis quatre, etc. Nous nunca poll. Ce système est en production sans erreur depuis environ deux ans.
En FileSystemWatcher peut également manquer des changements en période de forte activité, si le nombre de changements mis en file d'attente dépasse la mémoire tampon fournie. Il ne s'agit pas d'une limitation de la classe .NET en soi, mais de l'infrastructure Win32 sous-jacente. D'après notre expérience, la meilleure façon de minimiser ce problème est de mettre les notifications en file d'attente aussi rapidement que possible et de les traiter dans un autre thread.
Comme mentionné par @ChillTemp ci-dessus, le watcher peut ne pas fonctionner sur les partages non-Windows. Par exemple, il ne fonctionnera pas du tout sur les lecteurs Novell montés.
Je suis d'accord pour dire qu'un bon compromis consiste à effectuer un sondage occasionnel pour détecter les changements manqués.
Notez également que l'observateur du système de fichiers n'est pas fiable sur les partages de fichiers. En particulier si le partage de fichiers est hébergé sur un serveur non Windows. FSW ne doit pas être utilisé pour des tâches critiques. Il doit être utilisé avec une interrogation occasionnelle pour vérifier qu'il n'a rien manqué.
Personnellement, j'ai utilisé le FileSystemWatcher sur un système de production, et cela a bien fonctionné. Au cours des six derniers mois, il n'a pas eu le moindre problème en fonctionnant 24 heures sur 24 et 7 jours sur 7. Il surveille un seul dossier local (qui est partagé). Nous avons un nombre relativement faible d'opérations de fichiers qu'il doit gérer (10 événements déclenchés par jour). Je n'ai jamais eu à m'en préoccuper. Je l'utiliserais à nouveau si je devais prendre une nouvelle décision.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
