Estoy desarrollando un fragmento de código C que usa ReadDirectoryChangesW() para supervisar los cambios bajo un directorio en Windows. He leído las entradas de MSDN relacionadas para ReadDirectoryChangesW() y la estructura FILE_NOTIFY_INFORMATION, así como otras piezas de documentación. En este punto, he logrado monitorear múltiples directorios sin problemas aparentes en el monitoreo en sí. El problema es que los nombres de archivo puestos en la estructura FILE_NOTIFY_INFORMATION por esta función no son canónicos.¿Cómo lidiar con ReadDirectoryChangesW() de Windows y su salida mixta de nombre largo/corto?
Según MSDN pueden ser en forma larga o corta. He encontrado varias publicaciones que sugieren el almacenamiento en caché de rutas cortas y largas para manejar este caso. Desafortunadamente, según mis propias pruebas en un sistema con Windows 7, esto no es suficiente para eliminar el problema, porque no hay solo dos alternativas para cada nombre de archivo. El problema es que en un nombre de ruta CADA COMPONENTE puede estar en forma larga o corta. todas las siguientes rutas de acceso pueden hacer referencia al mismo archivo:
c: \ ~ 1 \ MYPROG ~ 1 \ MYDATA ~ 1.TXT
c: \ ~ 1 \ MYPROG ~ 1 \ MyDataFile.txt
c: \ ~ 1 \ MiPrograma \ MYDATA ~ 1.TXT
c: \ ~ 1 \ MiPrograma \ MyDataFile.txt
c: \ archivos de programa \ MYPROG ~ 1 \ ~ 1 MYDATA .TXT
...
y por lo que puedo decir de mis pruebas con cmd.exe son perfectamente aceptables. Básicamente, el número de rutas válidas para cada archivo se eleva exponentialy con el número de componentes en su nombre de ruta.
Desafortunadamente, ReadDirectoryChangesW() parece rellenar su búfer de salida con los nombres de archivo proporcionados a la llamada del sistema que causa cada operación. Por ejemplo, si usa los comandos cmd.exe para crear, cambiar el nombre, eliminar e.t.c. archivos, FILE_NOTIFY_INFORMATION contendrá los nombres de archivo como se especifica en la línea de comando.
Ahora, en la mayoría de los casos podría usar GetLongPathName() y mis amigos para obtener una ruta única para mi uso. Lamentablemente, eso no se puede hacer al eliminar archivos: cuando recibo la notificación, el archivo ya no está y las funciones Get * PathName() no funcionarán.
Por el momento estoy pensando en usar un caché más extenso para determinar qué rutas alternativas utilizan las aplicaciones para cada archivo, lo que manejaría cualquier caso, excepto el que decida eliminar un archivo de la nada con un nombre de ruta mixto no visto Y estoy pensando en la extracción de datos creativos a partir de los eventos de modificación del directorio padre y volviendo a consultar el directorio real para ese caso.
¿Alguna sugerencia para una manera más fácil de hacer esto?
PS1: Si bien las revistas de cambios se ocuparían de esto de manera efectiva (espero) no creo poder utilizarlas, debido a sus vínculos con NTFS y la falta de privilegios de administrador para mi aplicación. Prefiero no ir allí, a menos que esté absolutamente obligado a hacerlo.
PS2: Por favor, tenga en cuenta que codificaré principalmente en Unix, así que se gentil ...
Si todo lo demás falla, ¿quizás funcionará un controlador de minifiltro? – wj32
Creo que eso es lo que hacen la mayoría de los programas antivirus y supongo que sería LA solución para este problema. Desafortunadamente, requiere la instalación de derechos de administrador del sistema, y al igual que en Change Journals, la arquitectura de mi aplicación sería mucho más compleja, ya que tendría que considerar cuestiones de seguridad y estabilidad con las que no tengo que lidiar ahora. Y no olvidemos las dificultades inherentes de escribir un controlador kernel-mode o cuasi-kernel-mode para cualquier sistema operativo. – thkala
Ah, y por el momento parece un poco excesivo controlar todo solo para ver un par de directorios de usuarios. Gracias por la sugerencia, aunque ... – thkala