FileSystemWatcher vs Polling, um nach Dateiänderungen zu suchen

Ich muss eine Anwendung einrichten, die nach Dateien sucht, die in einem Verzeichnis sowohl lokal als auch auf einem Netzwerklaufwerk erstellt werden.

Wäre die FileSystemWatcheroder Abfrage auf einem Timer die beste Option. Ich habe beide Methoden in der Vergangenheit verwendet, aber nicht ausgiebig.

Welche Probleme (Leistung, Zuverlässigkeit usw.) gibt es bei beiden Methoden?

Ich habe gesehen, dass der Dateisystem-Watcher in Produktions- und Testumgebungen ausfällt. Ich halte es jetzt für eine Annehmlichkeit, aber ich halte es nicht für zuverlässig. Mein Muster war es, mit dem Dateisystem-Watcher nach Änderungen zu suchen, aber gelegentlich nach fehlenden Dateiänderungen zu suchen.

Bearbeiten: Wenn Sie eine Benutzeroberfläche haben, können Sie Ihrem Benutzer auch die Möglichkeit geben, Änderungen zu "aktualisieren", anstatt sie abzufragen. Ich würde dies mit einem Dateisystem-Watcher kombinieren.

Das größte Problem, das ich hatte, ist das Fehlen von Dateien, wenn der Puffer voll ist. Einfach zu reparieren - erhöhen Sie einfach den Puffer. Denken Sie daran, dass es die Dateinamen und Ereignisse enthält. Erhöhen Sie es daher auf die erwartete Anzahl von Dateien (Versuch und Irrtum). Es wird Speicher verwendet, der nicht ausgelagert werden kann, sodass andere Prozesse möglicherweise zur Seite gezwungen werden, wenn der Speicher knapp wird.

Hier ist der MSDN-Artikel zum Puffer: FileSystemWatcher .. ::. InternalBufferSize-Eigenschaft

Pro MSDN:

Das Erhöhen der Puffergröße ist teuer, da es aus nicht ausgelagertem Speicher stammt, der nicht auf die Festplatte ausgelagert werden kann. Halten Sie den Puffer daher so klein wie möglich. Verwenden Sie die Eigenschaften NotifyFilter und IncludeSubdirectories, um unerwünschte Änderungsbenachrichtigungen herauszufiltern, um einen Pufferüberlauf zu vermeiden.

Wir verwenden 16 MB aufgrund einer großen Charge, die auf einmal erwartet wird. Funktioniert gut und verpasst nie eine Datei.

Wir lesen auch alle Dateien, bevor wir anfangen, auch nur eine zu verarbeiten. Lassen Sie die Dateinamen sicher zwischengespeichert (in unserem Fall in eine Datenbanktabelle) und verarbeiten Sie sie dann.

Bei Problemen mit der Dateisperrung starte ich einen Prozess, der darauf wartet, dass die Datei entsperrt wird, und eine Sekunde, dann zwei, dann vier usw. wartet. Wir wählen nie ab. Dieser ist seit etwa zwei Jahren fehlerfrei in Produktion.

Das FileSystemWatcherkann auch Änderungen während der Stoßzeiten übersehen, wenn die Anzahl der Änderungen in der Warteschlange den bereitgestellten Puffer überläuft. Dies ist keine Einschränkung der .NET-Klasse an sich, sondern der zugrunde liegenden Win32-Infrastruktur. Nach unserer Erfahrung besteht der beste Weg, um dieses Problem zu minimieren, darin, die Benachrichtigungen so schnell wie möglich aus der Warteschlange zu entfernen und sie in einem anderen Thread zu bearbeiten.

Wie oben von @ChillTemp erwähnt, funktioniert der Watcher möglicherweise nicht mit Nicht-Windows-Freigaben. Beispielsweise funktioniert es auf gemounteten Novell-Laufwerken überhaupt nicht.

Ich bin damit einverstanden, dass ein guter Kompromiss darin besteht, gelegentlich eine Umfrage durchzuführen, um verpasste Änderungen festzustellen.

Beachten Sie auch, dass der Dateisystem-Watcher auf Dateifreigaben nicht zuverlässig ist. Insbesondere, wenn die Dateifreigabe auf einem Nicht-Windows-Server gehostet wird. FSW sollte nicht für kritische Zwecke verwendet werden. Oder sollte mit einer gelegentlichen Umfrage verwendet werden, um zu überprüfen, ob nichts übersehen wurde.

Persönlich habe ich das FileSystemWatcherauf einem Produktionssystem verwendet, und es hat gut funktioniert. In den letzten 6 Monaten gab es keinen einzigen Schluckauf, der rund um die Uhr lief. Es überwacht einen einzelnen lokalen Ordner (der gemeinsam genutzt wird). Wir haben eine relativ kleine Anzahl von Dateioperationen, die verarbeitet werden müssen (10 Ereignisse pro Tag). Ich musste mir nie Sorgen machen. Ich würde es wieder benutzen, wenn ich die Entscheidung neu treffen müsste.

Ich verwende derzeit die FileSystemWatcherXML-Datei, die durchschnittlich alle 100 Millisekunden aktualisiert wird.

Ich habe festgestellt, dass FileSystemWatcherSie niemals Probleme mit lokalen Dateien haben sollten , solange das richtig konfiguriert ist .

Ich habe keine Erfahrung mit Remote-Dateiüberwachung und Nicht-Windows-Freigaben.

Ich würde das Abrufen der Datei als redundant betrachten und den Overhead nicht wert sein, es sei denn, Sie misstrauen von Natur aus FileSystemWatcherden Einschränkungen, die alle anderen hier aufgeführt haben (Nicht-Windows-Freigaben und Remote-Dateiüberwachung).

Ich würde mit Umfragen gehen.

Netzwerkprobleme führen FileSystemWatcherdazu, dass das Ereignis unzuverlässig ist (selbst wenn das Fehlerereignis überlastet wird).

Ich habe Probleme bei der Verwendung FileSystemWatcherauf Netzwerkfreigaben. Wenn Sie sich in einer reinen Windows-Umgebung befinden, ist dies möglicherweise kein Problem, aber ich habe eine NFS-Freigabe angesehen. Da NFS zustandslos ist, gab es keine Benachrichtigung, als sich die von mir beobachtete Datei änderte.

Ich hatte einige große Probleme mit FSW auf Netzwerklaufwerken: Das Löschen einer Datei löste immer das Fehlerereignis aus, niemals das gelöschte Ereignis. Ich habe keine Lösung gefunden, deshalb vermeide ich jetzt das FSW und verwende Polling.

Erstellungsereignisse hingegen funktionierten einwandfrei. Wenn Sie also nur auf die Dateierstellung achten müssen, können Sie sich für den FSW entscheiden.

Außerdem hatte ich überhaupt keine Probleme mit lokalen Ordnern, egal ob geteilt oder nicht.

Die schnellstmögliche Rückkehr von der Ereignismethode mithilfe eines anderen Threads löste das Problem für mich:

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

Die Verwendung von FSW und Polling ist meiner Meinung nach eine Verschwendung von Zeit und Ressourcen, und ich bin überrascht, dass erfahrene Entwickler dies vorschlagen. Wenn Sie Polling verwenden müssen, um nach "FSW-Fehlern" zu suchen, können Sie FSW natürlich ganz verwerfen und nur Polling verwenden.

Ich versuche derzeit zu entscheiden, ob ich FSW oder Polling für ein von mir entwickeltes Projekt verwenden werde. Wenn Sie die Antworten lesen, ist es offensichtlich, dass es Fälle gibt, in denen FSW die Anforderungen perfekt abdeckt, während Sie in anderen Fällen Abfragen benötigen . Leider hat sich keine Antwort tatsächlich mit dem Leistungsunterschied (falls vorhanden) befasst , sondern nur mit den "Zuverlässigkeitsproblemen". Gibt es jemanden, der diesen Teil der Frage beantworten kann?

BEARBEITEN: Der Punkt von nmclean für die Gültigkeit der Verwendung von FSW und Polling (Sie können die Diskussion in den Kommentaren lesen, wenn Sie interessiert sind) scheint eine sehr rationale Erklärung zu sein, warum es Situationen geben kann, in denen sowohl FSW als auch Polling verwendet werden effizient. Vielen Dank, dass Sie das für mich (und alle anderen, die die gleiche Meinung haben) beleuchtet haben , nmclean .

Arbeitslösung für die Arbeit mit create event statt change

Auch zum Kopieren, Ausschneiden, Einfügen, Verschieben.

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
                {
                }          
        }
}

Lösung für diesen Datei-Watcher beim Ändern des Dateiattributereignisses mithilfe statischen Speichers

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;
    }
}

Dies ist eine Problemumgehungslösung für dieses Problem mehrerer auslösender Ereignisse.

Ich würde sagen, verwenden Sie Polling, insbesondere in einem TDD-Szenario, da es viel einfacher ist, das Vorhandensein von Dateien zu verspotten / zu stubben oder auf andere Weise, wenn das Polling-Ereignis ausgelöst wird, als sich auf das "unkontrolliertere" fsw-Ereignis zu verlassen. + dazu, dass an einer Reihe von Apps gearbeitet wurde, die von fsw-Fehlern geplagt wurden.