Cómo mantener ReadDirectoryChangesW de cambios de archivos faltantes

Question

Hay muchas publicaciones en Internet sobre la función de API ReadDirectoryChangesW que faltan archivos cuando hay mucha actividad de archivos. La mayoría culpa a la velocidad a la que se llama el bucle de función ReadDirectoryChangesW. Esta es una suposición incorrecta. La mejor explicación que he visto es en el siguiente post, el comentario el lunes 14 de abril de, 2008 2:15:27 PM

http://social.msdn.microsoft.com/forums/en-US/netfxbcl/thread/4465cafb-f4ed-434f-89d8-c85ced6ffaa8/

El resumen es que los informes la función de ReadDirectoryChangesW archivo cambia cuando salen de la cola de grabación de archivos retrospectivos, no como se agregan. Y si se agregan demasiados antes de comprometerse, pierde aviso en algunos de ellos. Puede ver esto con su implementación, si solo escribe un programa para generar más de 1000 archivos en un directorio muy rápido. Simplemente cuente cuántos avisos de eventos de archivos recibe y verá que hay momentos en que no los recibirá todos.

La pregunta es, ¿alguien ha encontrado un método confiable para usar la función ReadDirectoryChangesW sin tener que vaciar el volumen cada vez? Esto no está permitido si el usuario no es un administrador y también puede tomar algún tiempo para completar.

Answer 1

Si la API no es confiable, una solución alternativa puede ser su única opción. Eso, por supuesto, probablemente implica el seguimiento de los últimos nombres modificados y de archivos. Lo que esto no significa es que necesita sondear cuando busca cambios, en su lugar, puede usar FileSystemWatcher como medio para activar la verificación.

Así que si usted no perder de vista los últimos 50-100 veces la ReadDirectoryChangesW sucedió /FSW evento, y ves que se está llamando rápidamente, puede detectar esto y desencadenar la condición especial para obtener todos los archivos que se han cambiado (y establecer una bandera para evitar eventos de FSW falsos en el futuro temporalmente) en unos pocos segundos.

Dado que algunas personas están confundidas en los comentarios acerca de esta solución, les propongo que controlen qué tan rápidos están llegando los eventos desde ReadDirectoryChangesW y cuando llegan demasiado rápido, intenten intentar una solución (generalmente un barrido manual de un directorio).

Answer 2

Me encontré con el mismo problema. Pero no encontré una solución que garantice la obtención de todos los eventos. En varias pruebas, pude saber que la función ReadDirectoryChangesW se debe volver a llamar lo más rápido posible después de que se devuelva la función GetQueuedCompletionStatus. Supongo que si la velocidad de procesamiento del sistema de archivos es mucho más rápida que la velocidad de procesamiento de mi aplicación, la aplicación podría perder algunos eventos.

De todos modos, separé una lógica de análisis de una lógica de monitorización y coloqué una lógica de análisis en un hilo.

Answer 3

Nunca hemos visto que ReadDirectoryChangesW sea 100% confiable. Pero, la mejor manera de manejarlo es separar el "informe" del "manejo".

Mi implementación tiene un hilo que tiene un solo trabajo, para volver a poner en cola todos los eventos. Luego un segundo hilo para procesar mi cola intermedia. Básicamente, desea impedir el informe de eventos lo menos posible.

En situaciones de CPU elevadas, también puede impedir el informe de eventos de vigilantes.