2008-10-21 11 views
12

de Windows 6 (Vista y Server 2008) apoyar los enlaces simbólicos apropiados, que se pueden crear a través de la función CreateSymbolicLink. Pero no parece haber una función correspondiente para interrogar a un enlace simbólico para obtener la ruta del objetivo del enlace.¿Cómo puedo acceder mediante programación a la ruta de destino de un enlace simbólico de Windows?

He descubierto que los enlaces simbólicos son una implementación de los puntos de análisis, por lo que las funciones de punto de análisis se pueden utilizar para obtener la ruta de destino. Pero los archivos de encabezado que necesito para usar puntos de análisis parecen venir con el Windows Driver Kit. Configurar este kit con VS2008 parece ser una tarea no trivial.

¿Hay una buena función simple que he perdido para la obtención de destino de un vínculo, o es lo que realmente tiene que configurar un entorno de desarrollo de controladores de Windows sólo para escribir código para acceder a esta información?

EDIT: Adam Mitz se le ocurrió la sugerencia de GetFinalPathNameByHandle. Esta función funciona muy bien para enlaces simbólicos locales, pero no parece funcionar para resolver enlaces remotos (a través de una ruta UNC).

EDIT 2: A petición de Adán, aquí hay más detalles de lo que he intentado:

Inicialmente fui por el camino de FSCTL_GET_REPARSE_POINT/DeviceIoControl, pero que produce una estructura REPARSE_DATA_BUFFER. Los encabezados que definen esta estructura parecen existir únicamente dentro del Windows Driver Kit.

GetFinalPathNameByHandle() funciona bien cuando el enlace existe en un disco local (C:\...\link etc.). Curiosamente, me di cuenta que podía obtener el identificador para el enlace - y así conseguir el objetivo - el uso de CreateFileW() si el indicador FILE_FLAG_OPEN_REPARSE_POINT se especificó o no, independientemente de si existe el archivo de destino.

Cuando CreateFileW() y GetFinalPathNameByHandle() se utilizan para interrogar a un enlace remoto (\\?\UNC\....), las cosas comienzan a deshacerse. Si se especifica FILE_FLAG_OPEN_REPARSE_POINT, GetFinalPathNameByHandle() siempre devuelve la ruta del enlace, no la ruta de destino. Si no se especifica FILE_FLAG_OPEN_REPARSE_POINT, se devuelve la ruta de destino, pero solo si el destino existe y está en la misma máquina que el enlace. Si el enlace apunta a otra máquina, recibo un error de permisos de red. Si el enlace apunta a un archivo local que no existe, aparece un error de archivo no encontrado.

+0

Aclare si el enlace simbólico mismo está en un servidor remoto (a través de UNC) o si se trata del destino de enlace simbólico que es una ruta UNC. –

+0

Además, no creo que necesite DDK para leer puntos de análisis (no hay puntos de análisis). Consulte el indicador FILE_FLAG_OPEN_REPARSE_POINT en CreateFile o el indicador FSCTL_GET_REPARSE_POINT para DeviceIoControl. Que estos ayuden o no depende de tu respuesta a mi comentario anterior. –

+0

Explorer lo hace de alguna manera, dudo que sea directamente mediante el envío de IO_CTL. Pruébalo: crea un enlace simbólico de directorio, lo propiedades y obtendrás una pestaña de "acceso directo" con un destino atenuado. – Fowl

Respuesta

13

GetFinalPathNameByHandle

Un camino final es el camino que es devueltos cuando una ruta de acceso es totalmente resuelto. Por ejemplo, para un enlace simbólico llamado "C: \ tmp \ mydir" que apunta a "D: \ yourdir", la ruta final del sistema de archivos sería "D: \ yourdir".

+0

@ Adam, desafortunadamente, mientras GetFinalPathNameByHandle() funciona para un enlace simbólico local, devuelve el enlace, no el destino para enlaces simbólicos basados ​​en UNC remotos. Entonces, he "reabierto" la pregunta. –

+0

Creo que respondí la pregunta como se le preguntó (lo mismo que con su pregunta de JNI/Mock BTW ... ejem). Tal vez esta es una nueva pregunta. –

+0

GetFinalPathNameByHandle es básicamente la respuesta, si uno solo quiere usar enlaces locales. Sin embargo, parece que hay un error en la función en lo que respecta a los enlaces remotos. Así que he marcado esto como la respuesta correcta una vez más y documenté la advertencia. –

Cuestiones relacionadas