FileSystemWatcher vs interrogation pour surveiller les modifications de fichiers

J'ai besoin de configurer une application qui surveille les fichiers créés dans un répertoire, à la fois localement ou sur un lecteur réseau.

Le FileSystemWatcherou l'interrogation sur une minuterie serait la meilleure option. J'ai utilisé les deux méthodes dans le passé, mais pas de manière extensive.

Quels sont les problèmes (performances, fiabilité, etc.) avec l'une ou l'autre méthode?

J'ai vu l'échec de l'observateur du système de fichiers dans les environnements de production et de test. Je considère maintenant que c'est pratique, mais je ne le considère pas comme fiable. Mon modèle a été de surveiller les changements avec l'observateur du système de fichiers, mais d'interroger occasionnellement pour détecter les changements de fichiers manquants.

Modifier: si vous disposez d'une interface utilisateur, vous pouvez également donner à votre utilisateur la possibilité de "rafraîchir" les modifications au lieu d'interroger. Je combinerais cela avec un observateur de système de fichiers.

Le plus gros problème que j'ai eu est des fichiers manquants lorsque la mémoire tampon est pleine. Facile à réparer - augmentez simplement le tampon. N'oubliez pas qu'il contient les noms de fichiers et les événements, augmentez-le donc au nombre de fichiers attendu (essais et erreurs). Il utilise de la mémoire qui ne peut pas être paginée, de sorte qu'il pourrait forcer d'autres processus à paginer si la mémoire devient faible.

Voici l'article MSDN sur le tampon: FileSystemWatcher .. ::. Propriété InternalBufferSize

Par MSDN:

L'augmentation de la taille de la mémoire tampon coûte cher, car elle provient de la mémoire non paginée qui ne peut pas être échangée sur le disque, alors gardez la mémoire tampon aussi petite que possible. Pour éviter un dépassement de mémoire tampon, utilisez les propriétés NotifyFilter et IncludeSubdirectories pour filtrer les notifications de modification indésirables.

Nous utilisons 16 Mo en raison d'un lot important attendu à la fois. Fonctionne bien et ne manque jamais un fichier.

Nous lisons également tous les fichiers avant de commencer à en traiter un seul ... récupérez les noms de fichiers en toute sécurité (dans notre cas, dans une table de base de données), puis traitez-les.

Pour les problèmes de verrouillage de fichier, je lance un processus qui attend que le fichier soit déverrouillé en attendant une seconde, puis deux, puis quatre, et cetera. Nous ne sondons jamais . Celui-ci est en production sans erreur depuis environ deux ans.

Le FileSystemWatcherpeut également manquer des modifications pendant les périodes de pointe, si le nombre de modifications 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, le meilleur moyen de minimiser ce problème est de retirer les notifications de la file d'attente le plus rapidement possible et de les traiter sur un autre fil.

Comme mentionné par @ChillTemp ci-dessus, l'observateur peut ne pas fonctionner sur les partages non Windows. Par exemple, cela ne fonctionnera pas du tout sur les lecteurs Novell montés.

Je conviens qu'un bon compromis est de faire un sondage occasionnel pour relever les changements manqués.

Notez également que l'observateur du système de fichiers n'est pas fiable sur les partages de fichiers. Surtout si le partage de fichiers est hébergé sur un serveur non Windows. FSW ne doit pas être utilisé pour quelque chose de critique. Ou devrait être utilisé avec un sondage occasionnel pour vérifier qu'il n'a rien manqué.

Personnellement, j'ai utilisé le FileSystemWatchersur un système de production, et cela a bien fonctionné. Au cours des 6 derniers mois, il n'y a pas eu un seul hoquet fonctionnant 24x7. Il surveille un seul dossier local (qui est partagé). Nous avons un nombre relativement restreint d'opérations sur les fichiers à gérer (10 événements déclenchés par jour). Ce n'est pas quelque chose dont j'ai jamais eu à m'inquiéter. Je l'utiliserais à nouveau si je devais refaire la décision.

J'utilise actuellement le FileSystemWatcher sur un fichier XML mis à jour en moyenne toutes les 100 millisecondes.

J'ai trouvé que tant que le FileSystemWatcherest correctement configuré, vous ne devriez jamais avoir de problèmes avec le local fichiers .

Je n'ai aucune expérience de l'observation de fichiers à distance et des partages non Windows.

Je considérerais que l'interrogation du fichier est redondante et ne vaut pas la peine, à moins que vous ne vous méfiiez intrinsèquement du FileSystemWatcherou que vous ayez directement expérimenté les limitations que tout le monde a répertoriées ici (partages non Windows et observation de fichiers à distance).

J'irais avec le sondage.

Les problèmes de réseau font que le FileSystemWatchern'est pas fiable (même lors de la surcharge de l'événement d'erreur).

J'ai rencontré des problèmes lors de l'utilisation FileSystemWatcherdes partages réseau. Si vous êtes dans un environnement Windows pur, ce n'est peut-être pas un problème, mais je regardais un partage NFS et comme NFS est sans état, il n'y a jamais eu de notification lorsque le fichier que je regardais a changé.

J'ai eu de gros problèmes avec FSW sur les lecteurs réseau: la suppression d'un fichier renvoyait toujours l'événement d'erreur, jamais l'événement supprimé. Je n'ai pas trouvé de solution, alors j'évite maintenant le FSW et j'utilise le sondage.

Les événements de création, en revanche, fonctionnaient bien, donc si vous n'avez besoin que de surveiller la création de fichiers, vous pouvez opter pour le FSW.

De plus, je n'ai eu aucun problème sur les dossiers locaux, qu'ils soient partagés ou non.

Le retour de la méthode événementielle le plus rapidement possible, en utilisant un autre thread, a résolu le problème pour moi:

private void Watcher_Created(object sender, FileSystemEventArgs e)
{
    Task.Run(() => MySubmit(e.FullPath));
}

Utiliser à la fois FSW et le sondage est une perte de temps et de ressources, à mon avis, et je suis surpris que des développeurs expérimentés le suggèrent. Si vous devez utiliser l'interrogation pour vérifier d'éventuels "échecs FSW", vous pouvez, naturellement, supprimer complètement FSW et n'utiliser que l'interrogation.

J'essaie actuellement de décider si j'utiliserai FSW ou si je ferai des sondages pour un projet que je développe. En lisant les réponses, il est évident qu'il y a des cas où FSW couvre parfaitement les besoins, alors que d'autres fois, vous avez besoin d'un sondage. Malheureusement, aucune réponse n'a réellement traité de la différence de performance (le cas échéant), uniquement des problèmes de «fiabilité». Quelqu'un peut-il répondre à cette partie de la question?

MODIFIER: nmclean le point de pour la validité de l'utilisation à la fois de FSW et d'interrogation (vous pouvez lire la discussion dans les commentaires, si vous êtes intéressé) semble être une explication très rationnelle pourquoi il peut y avoir des situations où l'utilisation à la fois d'un FSW et de l'interrogation est efficace. Merci d'avoir fait la lumière là-dessus pour moi (et pour toute autre personne ayant le même avis), nmclean .

Solution de travail pour travailler avec créer un événement au lieu de modifier

Même pour copier, couper, coller, déplacer.

class Program
{        

        static void Main(string[] args)
        {
            string SourceFolderPath = "D:\\SourcePath";
            string DestinationFolderPath = "D:\\DestinationPath";
            FileSystemWatcher FileSystemWatcher = new FileSystemWatcher();
            FileSystemWatcher.Path = SourceFolderPath;
            FileSystemWatcher.IncludeSubdirectories = false;
            FileSystemWatcher.NotifyFilter = NotifyFilters.FileName;   // ON FILE NAME FILTER       
            FileSystemWatcher.Filter = "*.txt";         
             FileSystemWatcher.Created +=FileSystemWatcher_Created; // TRIGGERED ONLY FOR FILE GOT CREATED  BY COPY, CUT PASTE, MOVE  
            FileSystemWatcher.EnableRaisingEvents = true;

            Console.Read();
        }     

        static void FileSystemWatcher_Created(object sender, FileSystemEventArgs e)
        {           
                string SourceFolderPath = "D:\\SourcePath";
                string DestinationFolderPath = "D:\\DestinationPath";

                try
                {
                    // DO SOMETING LIKE MOVE, COPY, ETC
                    File.Copy(e.FullPath, DestinationFolderPath + @"\" + e.Name);
                }
                catch
                {
                }          
        }
}

Solution pour cet observateur de fichiers lors de l'événement de changement d'attribut de fichier à l'aide du stockage statique

class Program
{
    static string IsSameFile = string.Empty;  // USE STATIC FOR TRACKING

    static void Main(string[] args)
    {
         string SourceFolderPath = "D:\\SourcePath";
        string DestinationFolderPath = "D:\\DestinationPath";
        FileSystemWatcher FileSystemWatcher = new FileSystemWatcher();
        FileSystemWatcher.Path = SourceFolderPath;
        FileSystemWatcher.IncludeSubdirectories = false;
        FileSystemWatcher.NotifyFilter = NotifyFilters.LastWrite;          
        FileSystemWatcher.Filter = "*.txt";         
        FileSystemWatcher.Changed += FileSystemWatcher_Changed;
        FileSystemWatcher.EnableRaisingEvents = true;

        Console.Read();
    }     

    static void FileSystemWatcher_Changed(object sender, FileSystemEventArgs e)
    {
        if (e.Name == IsSameFile)  //SKIPS ON MULTIPLE TRIGGERS
        {
            return;
        }
        else
        {
            string SourceFolderPath = "D:\\SourcePath";
            string DestinationFolderPath = "D:\\DestinationPath";

            try
            {
                // DO SOMETING LIKE MOVE, COPY, ETC
                File.Copy(e.FullPath, DestinationFolderPath + @"\" + e.Name);
            }
            catch
            {
            }
        }
        IsSameFile = e.Name;
    }
}

Il s'agit d'une solution de contournement pour ce problème d'événement déclencheur multiple.

Je dirais utiliser l'interrogation, en particulier dans un scénario TDD, car il est beaucoup plus facile de simuler / stub la présence de fichiers ou autrement lorsque l'événement d'interrogation est déclenché que de s'appuyer sur l'événement fsw plus «incontrôlé». + à cela après avoir travaillé sur un certain nombre d'applications qui étaient en proie à des erreurs fsw.