FileSystemWatcher vs sondeo para ver los cambios de archivo

Necesito configurar una aplicación que vigile los archivos que se crean en un directorio, tanto localmente como en una unidad de red.

¿ FileSystemWatcherSería la mejor opción el sondeo en un temporizador? He usado ambos métodos en el pasado, pero no ampliamente.

¿Qué problemas (rendimiento, confiabilidad, etc.) existen con cualquiera de los métodos?

He visto fallar al observador del sistema de archivos en entornos de producción y prueba. Ahora lo considero una conveniencia, pero no lo considero confiable. Mi patrón ha sido observar los cambios con el observador del sistema de archivos, pero sondear ocasionalmente para detectar los cambios que faltan.

Editar: si tiene una interfaz de usuario, también puede darle a su usuario la posibilidad de "actualizar" los cambios en lugar de sondear. Combinaría esto con un observador del sistema de archivos.

El mayor problema que he tenido es la falta de archivos cuando el búfer se llena. Fácil de arreglar, simplemente aumente el búfer. Recuerde que contiene los nombres de archivos y eventos, así que aumente a la cantidad esperada de archivos (prueba y error). Utiliza memoria que no se puede paginar, por lo que podría forzar a otros procesos a buscar si la memoria es baja.

Aquí está el artículo de MSDN sobre el buffer: FileSystemWatcher .. ::. InternalBufferSize Property

Por MSDN:

El aumento del tamaño del búfer es costoso, ya que proviene de la memoria no paginada que no se puede cambiar al disco, por lo que debe mantener el búfer lo más pequeño posible. Para evitar un desbordamiento del búfer, use las propiedades NotifyFilter e IncludeSubdirectories para filtrar las notificaciones de cambios no deseados.

Usamos 16 MB debido a un gran lote esperado a la vez. Funciona bien y nunca pierde un archivo.

También leemos todos los archivos antes de comenzar a procesar incluso uno ... obtener los nombres de los archivos almacenados en caché de forma segura (en nuestro caso, en una tabla de base de datos) y luego procesarlos.

Para problemas de bloqueo de archivos, engendro un proceso que espera que el archivo se desbloquee esperando un segundo, luego dos, luego cuatro, etc. Nosotros no Poll. Esto ha estado en producción sin error durante aproximadamente dos años.

También FileSystemWatcherpuede perder los cambios durante las horas de mayor actividad, si el número de cambios en cola desborda el búfer proporcionado. Esto no es una limitación de la clase .NET per se, sino de la infraestructura subyacente de Win32. En nuestra experiencia, la mejor manera de minimizar este problema es retirar las notificaciones lo más rápido posible y tratarlas en otro hilo.

Como se mencionó anteriormente en @ChillTemp, el observador puede no funcionar en recursos compartidos que no sean de Windows. Por ejemplo, no funcionará en absoluto en unidades Novell montadas.

Estoy de acuerdo en que un buen compromiso es hacer una encuesta ocasional para recoger los cambios perdidos.

También tenga en cuenta que el observador del sistema de archivos no es confiable en los archivos compartidos. Particularmente si el recurso compartido de archivos está alojado en un servidor que no es de Windows. FSW no debe usarse para nada crítico. O debe usarse con una encuesta ocasional para verificar que no se haya perdido nada.

Personalmente, he usado FileSystemWatcherun sistema de producción y ha funcionado bien. En los últimos 6 meses, no ha tenido un solo problema las 24 horas del día, los 7 días de la semana. Está monitoreando una sola carpeta local (que se comparte). Tenemos un número relativamente pequeño de operaciones de archivos que tiene que manejar (10 eventos disparados por día). No es algo de lo que deba preocuparme. Lo usaría nuevamente si tuviera que rehacer la decisión.

Actualmente uso el FileSystemWatcheren un archivo XML que se actualiza en promedio cada 100 milisegundos.

He descubierto que, siempre que FileSystemWatcheresté configurado correctamente, nunca debería tener problemas con los archivos locales .

No tengo experiencia en la observación remota de archivos y recursos compartidos que no sean de Windows.

Consideraría que sondear el archivo es redundante y no vale la pena la sobrecarga a menos que desconfíe inherentemente FileSystemWatchero haya experimentado directamente las limitaciones que todos los demás aquí han enumerado (recursos compartidos que no son de Windows y observación remota de archivos).

Yo iría con las encuestas.

Los problemas de red hacen FileSystemWatcherque no sea confiable (incluso cuando se sobrecarga el evento de error).

Me he encontrado con problemas al usar FileSystemWatcheren recursos compartidos de red. Si está en un entorno puro de Windows, puede que no sea un problema, pero estaba viendo un recurso compartido NFS y dado que NFS no tiene estado, nunca hubo una notificación cuando el archivo que estaba viendo cambió.

Tuve algunos problemas importantes con FSW en las unidades de red: la eliminación de un archivo siempre generaba el evento de error, nunca el evento eliminado. No encontré una solución, así que ahora evito el FSW y uso el sondeo.

Los eventos de creación, por otro lado, funcionaron bien, por lo que si solo necesita observar la creación de archivos, puede optar por la FSW.

Además, no tuve ningún problema en las carpetas locales, sin importar si las compartía o no.

Volviendo del método de evento lo más rápido posible, usando otro hilo, resolvió el problema para mí:

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

Usar FSW y encuestas es una pérdida de tiempo y recursos, en mi opinión, y me sorprende que los desarrolladores experimentados lo sugieran. Si necesita usar el sondeo para verificar si hay "fallas de FSW", entonces, naturalmente, puede descartar FSW por completo y usar solo el sondeo.

Actualmente, estoy tratando de decidir si usaré FSW o sondeo para un proyecto que desarrolle. Al leer las respuestas, es obvio que hay casos en los que FSW cubre las necesidades a la perfección, mientras que otras veces, necesita encuestas. Desafortunadamente, ninguna respuesta ha tratado la diferencia de rendimiento (si la hay), solo los problemas de "confiabilidad". ¿Hay alguien que pueda responder esa parte de la pregunta?

EDITAR: el punto de nmclean para la validez del uso de FSW y encuestas (puede leer la discusión en los comentarios, si está interesado) parece ser una explicación muy racional de por qué puede haber situaciones en las que usar tanto FSW como encuestas es eficiente. Gracias por arrojar luz sobre eso para mí (y para cualquier otra persona que tenga la misma opinión), nmclean .

Solución de trabajo para trabajar con crear evento en lugar de cambio

Incluso para copiar, cortar, pegar, mover.

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

Solución para este observador de archivos mientras el evento de cambio de atributo de archivo utiliza almacenamiento estático

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

Esta es una solución alternativa para este problema de evento de activación múltiple.

Yo diría que use el sondeo, especialmente en un escenario TDD, ya que es mucho más fácil burlarse de la presencia de archivos o de otra manera cuando se desencadena el evento de sondeo que confiar en el evento fsw más "no controlado". + a eso de haber trabajado en varias aplicaciones plagadas de errores de FSW.