FileSystemWatcher vs polling per controllare le modifiche ai file

Devo installare un'applicazione che controlla la creazione di file in una directory, sia localmente che su un'unità di rete.

Il FileSystemWatcherpolling o il polling su un timer sarebbe l'opzione migliore. Ho usato entrambi i metodi in passato, ma non ampiamente.

Quali problemi (prestazioni, affidabilità ecc.) Ci sono con entrambi i metodi?

Ho visto il watcher del file system fallire negli ambienti di produzione e test. Ora lo considero una comodità, ma non lo considero affidabile. Il mio modello è stato quello di controllare le modifiche con il watcher del file system, ma occasionalmente il sondaggio per rilevare le modifiche ai file mancanti.

Modifica: se hai un'interfaccia utente, puoi anche dare al tuo utente la possibilità di "aggiornare" le modifiche invece del polling. Vorrei combinare questo con un osservatore del file system.

Il problema più grande che ho avuto è la mancanza di file quando il buffer si riempie. Facile da correggere: basta aumentare il buffer. Ricorda che contiene i nomi dei file e gli eventi, quindi aumentalo alla quantità prevista di file (prova ed errore). Usa una memoria che non può essere paginata, quindi potrebbe forzare altri processi alla pagina se la memoria si esaurisce.

Ecco l'articolo MSDN sul buffer: FileSystemWatcher .. ::. InternalBufferSize Proprietà

Per MSDN:

L'aumento della dimensione del buffer è costoso, poiché proviene da memoria non paginata che non può essere scambiata su disco, quindi mantenere il buffer il più piccolo possibile. Per evitare un overflow del buffer, utilizzare le proprietà NotifyFilter e IncludeSubdirectories per filtrare le notifiche di modifica indesiderate.

Usiamo 16 MB a causa di un grande lotto previsto contemporaneamente. Funziona bene e non perde mai un file.

Leggiamo anche tutti i file prima di iniziare a elaborare anche uno ... prendere i nomi dei file memorizzati nella cache in modo sicuro (nel nostro caso, in una tabella del database) quindi elaborarli.

Per problemi di blocco dei file ho generato un processo che attende lo sblocco del file in attesa di un secondo, quindi due, quindi quattro, eccetera. Non facciamo mai sondaggi. Questo è stato in produzione senza errori per circa due anni.

L' FileSystemWatcherpuò anche perdere modifiche durante occupato volte, se il numero di modifiche in coda overflow del buffer fornito. Questa non è una limitazione della classe .NET in sé, ma dell'infrastruttura Win32 sottostante. Nella nostra esperienza, il modo migliore per ridurre al minimo questo problema è rimuovere le notifiche il più rapidamente possibile e gestirle su un altro thread.

Come menzionato da @ChillTemp sopra, l'osservatore potrebbe non funzionare su condivisioni non Windows. Ad esempio, non funzionerà affatto sulle unità Novell montate.

Concordo sul fatto che un buon compromesso sia fare un sondaggio occasionale per raccogliere eventuali modifiche perse.

Inoltre, il watcher del file system non è affidabile per le condivisioni di file. In particolare se la condivisione file è ospitata su un server non Windows. FSW non dovrebbe essere usato per nulla di critico. O dovrebbe essere usato con un sondaggio occasionale per verificare che non abbia perso nulla.

Personalmente, ho usato il FileSystemWatchersistema di produzione e ha funzionato bene. Negli ultimi 6 mesi, non ha avuto un singolo singhiozzo in esecuzione 24x7. Sta monitorando una singola cartella locale (che è condivisa). Abbiamo un numero relativamente piccolo di operazioni sui file che deve gestire (10 eventi generati al giorno). Non è qualcosa di cui mi debba mai preoccupare. Lo userei di nuovo se dovessi rifare la decisione.

Attualmente uso il FileSystemWatcherfile su XML che viene aggiornato in media ogni 100 millisecondi.

Ho scoperto che fintanto che FileSystemWatcherè configurato correttamente non dovresti mai avere problemi con i file locali .

Non ho esperienza sulla visualizzazione di file remoti e condivisioni non Windows.

Considererei ridondante il polling del file e non valga il sovraccarico a meno che tu non abbia intrinsecamente diffidenza FileSystemWatchero non abbia sperimentato direttamente i limiti elencati da tutti gli altri qui (condivisioni non Windows e controllo remoto dei file).

Andrei con il polling.

Problemi di rete causano l' FileSystemWatcheraffidabilità (anche in caso di sovraccarico dell'evento di errore).

Ho riscontrato problemi con FileSystemWatcherle condivisioni di rete. Se ti trovi in ​​un ambiente Windows puro, potrebbe non essere un problema, ma stavo guardando una condivisione NFS e poiché NFS è senza stato, non c'è mai stata una notifica quando il file che stavo guardando è cambiato.

Ho avuto alcuni grossi problemi con FSW su unità di rete: l'eliminazione di un file ha sempre generato l'evento di errore, mai l'evento eliminato. Non ho trovato una soluzione, quindi evito il FSW e utilizzo il polling.

D'altra parte, gli eventi di creazione hanno funzionato bene, quindi se devi solo guardare per la creazione di file, puoi scegliere FSW.

Inoltre, non ho avuto alcun problema con le cartelle locali, indipendentemente dal fatto che siano condivise o meno.

Tornando dal metodo dell'evento il più rapidamente possibile, usando un altro thread, ho risolto il problema per me:

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

Utilizzando sia FSW e polling è uno spreco di tempo e risorse, a mio parere, e mi sorprende che gli sviluppatori esperti suggeriscono che. Se è necessario utilizzare il polling per verificare la presenza di "errori FSW", è possibile, naturalmente, scartare completamente FSW e utilizzare solo il polling.

Attualmente sto cercando di decidere se usare FSW o il polling per un progetto che sviluppo. Leggendo le risposte, è ovvio che ci sono casi in cui FSW copre perfettamente le esigenze, mentre altre volte è necessario il polling. Sfortunatamente, nessuna risposta ha effettivamente affrontato la differenza di prestazioni (se presente), solo con i problemi di "affidabilità". C'è qualcuno che può rispondere a quella parte della domanda?

EDIT: il punto di nmclean per la validità dell'utilizzo sia di FSW che del polling (puoi leggere la discussione nei commenti, se sei interessato) sembra essere una spiegazione molto razionale perché ci possono essere situazioni in cui l'uso sia di un FSW che del polling è efficiente. Grazie per far luce su questo per me (e chiunque altro abbia la stessa opinione), nmclean .

Soluzione funzionante per lavorare con create event anziché change

Anche per copiare, tagliare, incollare, spostare.

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

Soluzione per questo osservatore di file mentre l'evento di modifica dell'attributo del file utilizza l'archiviazione statica

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

Questa è una soluzione alternativa per questo problema di evento scatenante multiplo.

Direi usare il polling, specialmente in uno scenario TDD, poiché è molto più facile deridere / stub la presenza di file o altrimenti quando viene attivato l'evento di polling piuttosto che fare affidamento sull'evento fsw più "incontrollato". + a quello di aver lavorato su una serie di app afflitte da errori fsw.