FileSystemWatcher vs odpytywanie w poszukiwaniu zmian plików

Muszę skonfigurować aplikację, która śledzi pliki tworzone w katalogu, zarówno lokalnie, jak i na dysku sieciowym.

Czy FileSystemWatchernajlepszym rozwiązaniem byłoby odpytywanie czasomierza lub. W przeszłości stosowałem obie metody, ale nie na szeroką skalę.

Jakie problemy (wydajność, niezawodność itp.) Występują w przypadku obu metod?

Widziałem awarię obserwatora systemu plików w środowiskach produkcyjnych i testowych. Teraz uważam to za wygodę, ale nie uważam tego za wiarygodne. Mój wzorzec polegał na tym, że obserwowałem zmiany za pomocą obserwatora systemu plików, ale od czasu do czasu sondowałem, aby wykryć brakujące zmiany w plikach.

Edycja: jeśli masz interfejs użytkownika, możesz również dać użytkownikowi możliwość „odświeżania” zmian zamiast odpytywania. Połączyłbym to z obserwatorem systemu plików.

Największym problemem, jaki miałem, są brakujące pliki, gdy bufor się zapełni. Łatwe do naprawienia - po prostu zwiększ bufor. Pamiętaj, że zawiera nazwy plików i zdarzenia, więc zwiększ go do oczekiwanej liczby plików (metoda prób i błędów). Używa pamięci, której nie można stronicować, więc może zmusić inne procesy do stronicowania, jeśli pamięć się wyczerpie.

Oto artykuł MSDN dotyczący bufora: Właściwość FileSystemWatcher .. ::. InternalBufferSize

Według MSDN:

Zwiększenie rozmiaru bufora jest kosztowne, ponieważ pochodzi z pamięci niestronicowanej, której nie można zamienić na dysk, dlatego należy utrzymywać jak najmniejszy bufor. Aby uniknąć przepełnienia buforu, użyj właściwości NotifyFilter i IncludeSubdirectories w celu odfiltrowania niechcianych powiadomień o zmianach.

Używamy 16 MB ze względu na spodziewaną dużą partię jednorazowo. Działa dobrze i nigdy nie pomija pliku.

Czytamy również wszystkie pliki przed rozpoczęciem przetwarzania choćby jednego ... pobieramy nazwy plików z bezpiecznej pamięci podręcznej (w naszym przypadku do tabeli bazy danych), a następnie je przetwarzamy.

W przypadku problemów z blokowaniem plików uruchamiam proces, który czeka na odblokowanie pliku, czekając jedną sekundę, potem dwie, potem cztery i tak dalej. Nigdy nie sondujemy. To trwało bezbłędnie przez około dwa lata.

FileSystemWatcherMoże również brakuje zmiany podczas porach, jeżeli liczba oczekujących zmian przepełnienia bufora celu. Nie jest to ograniczenie samej klasy .NET, ale podstawowej infrastruktury Win32. Z naszego doświadczenia wynika, że ​​najlepszym sposobem na zminimalizowanie tego problemu jest jak najszybsze usunięcie powiadomień z kolejki i zajęcie się nimi w innym wątku.

Jak wspomniano powyżej w @ChillTemp, obserwator może nie działać na udziałach innych niż Windows. Na przykład nie będzie w ogóle działać na zamontowanych dyskach Novell.

Zgadzam się, że dobrym kompromisem jest okazjonalne przeprowadzanie ankiet w celu wykrycia wszelkich pominiętych zmian.

Należy również zauważyć, że obserwator systemu plików nie jest niezawodny w przypadku udziałów plików. Szczególnie jeśli udział plików jest hostowany na serwerze innym niż Windows. FSW nie powinno być używane do niczego krytycznego. Lub powinien być używany z okazjonalną ankietą, aby sprawdzić, czy nic nie pominęło.

Osobiście korzystałem z FileSystemWatchersystemu produkcyjnego i działa dobrze. W ciągu ostatnich 6 miesięcy nie miał ani jednej czkawki działającej 24x7. Monitoruje pojedynczy folder lokalny (który jest udostępniany). Mamy stosunkowo niewielką liczbę operacji na plikach, które musi obsłużyć (10 zdarzeń uruchamianych dziennie). To nie jest coś, o co kiedykolwiek musiałam się martwić. Użyłbym go ponownie, gdybym musiał ponownie podjąć decyzję.

Obecnie używam FileSystemWatcher pliku XML, który jest aktualizowany średnio co 100 milisekund.

Zauważyłem, że dopóki FileSystemWatcherjest poprawnie skonfigurowany, nigdy nie powinieneś mieć problemów z lokalnymi plikami.

Nie mam doświadczenia w zdalnym oglądaniu plików i udostępnianiu innym niż Windows.

Uznałbym, że odpytywanie pliku jest zbędne i nie jest warte narzutów, chyba że z natury nie ufasz FileSystemWatcherlub bezpośrednio doświadczyłeś ograniczeń, które wszyscy tu wymienili (udziały spoza systemu Windows i zdalne obserwowanie plików).

Poszedłbym z ankietą.

Problemy z siecią powodują, że aplikacja FileSystemWatcherjest zawodna (nawet podczas przeciążania zdarzenia błędu).

Mam problem z używaniem FileSystemWatcherna udziałach sieciowych. Jeśli pracujesz w czystym środowisku Windows, może to nie być problem, ale oglądałem udział NFS, a ponieważ NFS jest bezstanowy, nigdy nie było powiadomienia, gdy plik, który obserwowałem, zmienił się.

Miałem duże problemy z FSW na dyskach sieciowych: usunięcie pliku zawsze powodowało zdarzenie błędu, nigdy zdarzenie usunięte. Nie znalazłem rozwiązania, więc teraz unikam FSW i używam odpytywania.

Z drugiej strony zdarzenia tworzenia działały dobrze, więc jeśli potrzebujesz tylko patrzeć na tworzenie plików, możesz przejść do FSW.

Ponadto nie miałem żadnych problemów z folderami lokalnymi, bez względu na to, czy były udostępniane, czy nie.

Wracając jak najszybciej z metody eventowej, korzystając z innego wątku, rozwiązałem problem:

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

Moim zdaniem używanie zarówno FSW, jak i pollingu jest stratą czasu i zasobów i jestem zaskoczony, że sugerują to doświadczeni programiści. Jeśli potrzebujesz użyć odpytywania, aby sprawdzić, czy nie ma żadnych błędów FSW, możesz oczywiście całkowicie odrzucić FSW i używać tylko odpytywania.

Obecnie próbuję zdecydować, czy do projektu, który rozwijam, użyję FSW czy ankietowania. Czytając odpowiedzi, jest oczywiste, że zdarzają się przypadki, w których FSW doskonale zaspokaja potrzeby, innym razem potrzebne jest sondowanie. Niestety, żadna odpowiedź nie dotyczyła różnicy w wydajności (jeśli taka istnieje), a jedynie kwestie „niezawodności”. Czy jest ktoś, kto może odpowiedzieć na tę część pytania?

EDYCJA: argument nmclean dotyczący zasadności używania zarówno FSW, jak i odpytywania (możesz przeczytać dyskusję w komentarzach, jeśli jesteś zainteresowany) wydaje się być bardzo racjonalnym wyjaśnieniem, dlaczego mogą wystąpić sytuacje, w których użycie zarówno FSW, jak i odpytywania jest wydajny. Dziękuję za rzucenie światła na to dla mnie (i każdego, kto ma to samo zdanie), nmclean .

Działające rozwiązanie do pracy z utworzeniem wydarzenia zamiast zmiany

Nawet do kopiowania, wycinania, wklejania, przenoszenia.

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

Rozwiązanie dla tego obserwatora plików podczas zdarzenia zmiany atrybutu pliku przy użyciu pamięci statycznej

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

Jest to rozwiązanie obejścia tego problemu związanego z wieloma zdarzeniami wyzwalającymi.

Powiedziałbym, że używaj odpytywania, szczególnie w scenariuszu TDD, ponieważ znacznie łatwiej jest wyszydzać / odgiąć obecność plików lub w inny sposób, gdy zdarzenie odpytywania jest wyzwalane, niż polegać na bardziej „niekontrolowanym” zdarzeniu fsw. + do tego, że pracował nad wieloma aplikacjami, które były nękane przez błędy FSW.