2010-08-18 13 views
81

Con el sistema operativo Linux, existe el subsistema ionotify que notifica una aplicación de cambios al sistema de archivos.¿Hay algo como inotify en Windows?

Sin embargo, soy principalmente un usuario de Windows, por lo que me preguntaba si existe una API de sistema operativo similar para supervisar los cambios en el sistema de archivos.

+3

No creo que estas preguntas estén fuera de tema. La pregunta requiere una API de sistema operativo que sea muy diferente a cualquier herramienta/software-biblioteca.Puede ser que se pueda redactar de forma diferente, por ejemplo, cómo recibir notificaciones en una aplicación de Windows cuando se modifican determinados archivos o archivos. – balki

+0

Votaron para reabrir: La pregunta es pidiendo una alternativa comparable a una API de sistema operativo específica y me dice figuáticamente: "Soy de Inglaterra, donde uso un tenedor para comer, en Japón, ¿qué utensilio uso de manera similar? ? " La respuesta aceptada usando esa analogía es "usar palillos". – David

Respuesta

1

Hice un poco de búsqueda, me parece recordar haber visto algo similar para Windows. Hay FileSystemWatcher para .NET. Es principalmente para NT o XP y hacia adelante.

10

JNotify o FileMon de Microsoft.

+7

JNotify fue perfecto para mí porque necesitaba compatibilidad multiplataforma. Incluso pude escribir un solo script bash que funcionó en cygwin, mac y linux suponiendo solo que JAVA_HOME estuviera configurado correctamente. Esto ha sido una gran ayuda para la depuración de problemas en las máquinas de los clientes, cuando dicen "¡eliminó mi archivo!" De hecho, puedo mirar el registro e intentar descubrir cómo y cuándo sucedió eso. – cmyers

+1

FileMon ahora es ProcessMonitor https://technet.microsoft.com/en-us/sysinternals/bb896645 – MECU

38

Si está usando .net, use FileSystemWatcher. Más información aquí: http://msdn.microsoft.com/en-us/library/system.io.filesystemwatcher.aspx

Si está utilizando C, utilice FindFirstChangeNotification, FindNextChangeNotification, ReadDirectoryChangesW. Más información aquí: http://msdn.microsoft.com/en-us/library/aa365261(VS.85).aspx

En OSX, la API relevante es la fsevents API.

Todas son sutilmente diferentes entre sí, y todas tienen una fiabilidad cuestionable en los casos extremos. En general, no puede depender de estas API para obtener una vista completa de todos los cambios el 100% del tiempo. La mayoría de las personas que usan la supervisión del sistema de archivos lo combinan con escaneos periódicos para compensar la información perdida o incompleta de la aplicación api.

+4

¿Puede dar alguna cita sobre la "confiabilidad cuestionable en el caso de borde para inotify? – Pharaun

+15

Si un consumidor de un fs watcher api es más lento en la lectura de eventos que otro proceso al generarlos, el núcleo necesita mantener las modificaciones del sistema de archivos en el otro proceso (posiblemente de mayor prioridad) o permitir el crecimiento ilimitado del buffer. profundidad del buffer de inotify (como se documenta en la página man) está controlada por/proc/sys/fs/inotify/max_queued_events. Más allá de esto, recibe una notificación IN_Q_OVERFLOW - esto es bueno, pero aún se encuentra en una situación en la que es posible que deba volver a escanear de vez en cuando. time. – blucz

+0

Ah, sí, hace poco que estaba leyendo en la cola. Creo que este caso extremo dependerá de la cantidad de archivos que esté monitoreando g y también depende de si es fundamental seguir todos los cambios o si se pueden perder algunos. Pero ese es un buen punto. Gracias :) – Pharaun

2

FileSystemWatcher() no es confiable debido principalmente al hecho de que es el manejo de errores para el búfer observador es más o menos incompleto Debido a la falta de ruta y a la información detallada sobre el manejo de errores, Microsoft no le ofrece ninguna forma de recuperar o sondear manualmente el directorio de trabajo.

El JNotify para Windows tampoco es confiable porque este error^se deriva de win32. JNotify usa win32. Por lo tanto, no es diferente de FileSystemWatcher().

+0

pensando en cómo diseñar roles para resolver este problema de "velocidad"/"carrera"/"desbordamiento", me pregunté cómo lo hicieron los núcleos. Interesante. Esto también ocurre con la creación de redes y el registro. ¿Este problema tiene un nombre? – n611x007

+0

Sí, su nombre es "error". El error (win32) se ha dejado en todos los sistemas operativos creados por Microsoft hasta la fecha. Esto hace que cualquier sistema operativo de Microsoft no sea apto para una solución de tipo de observación de archivos. Tienes que ir * nix para lograrlo. A veces creo que han dejado intencionalmente este desbordamiento de búfer por razones de seguridad. –

+0

jaja .. sí ... es un nombre intencionado clúster kludge para que el sistema de archivos de microsoft no pueda ser visto intencionalmente. Es un error que dejaron debido a problemas de seguridad. –

8

Un poco tarde, pero ...

Windows tiene una instalación similar a los eventos OSX mediante el cual se puede monitorear eventos sin ejecutar una aplicación. El Windows USN Journal realiza un seguimiento de todos los cambios de archivos. Jeffrey Richter (autor de Windows avanzado) escribió un terrific article con muestras de trabajo para MSDN Journal.

MSDN documentation for USN Change Journals.

cambios USN Revistas son probablemente mejor si usted está construyendo aplicaciones como herramientas de copia de seguridad o índices que necesitan para controlar volúmenes enteros.

+0

Si el USN Journal es diferente, si se basa en evitar el comportamiento erróneo de 'FileSystemWatcher' |' FindFirstChangeNotification' [PhillipBrandonHolmes] (http://stackoverflow.com/users/1084830/) fue [hablando de] (http: //stackoverflow.com/a/17660295/611007)? – n611x007

+4

Ha pasado un tiempo desde que trabajé con esto, pero no usa FileSystemWatcher o FindFirstChangeNotification. Empecé a escribir un observador de eventos de Windows en Go, basado en gran medida en los ejemplos de Jeffery Richter. Por las pocas pruebas que hice, es sólido como una roca, y no pasa nada, similar a fsevents en OS X. Gist está aquí: https://gist.github.com/pkrnjevic/7219861 –

Cuestiones relacionadas