IOCTL_REDIR_QUERY_PATH IOCTL (ntifs.h)
El IOCTL_REDIR_QUERY_PATH código de control lo envían varios proveedores UNC (MUP) a los redireccionadores para determinar qué proveedor puede controlar una ruta de acceso UNC específica en una operación basada en nombres, normalmente una solicitud de IRP_MJ_CREATE. Esta solicitud se conoce como "resolución de prefijos".
MUP es un componente en modo kernel responsable de canalizar todos los accesos remotos del sistema de archivos que usan un nombre UNC a un redirector de red (el proveedor UNC) capaz de controlar las solicitudes del sistema de archivos remotos. MUP está implicado cuando se usa una ruta de acceso UNC como se muestra en el ejemplo siguiente que se podría ejecutar desde una línea de comandos:
notepad \\server\public\readme.txt
MUP no está implicado durante una operación que crea una letra de unidad asignada (por ejemplo, el comando "NET USE"). Esta operación se controla mediante el enrutador de varios proveedores (MPR) y un archivo DLL de proveedor WNet en modo de usuario para el redirector de red. Sin embargo, un archivo DLL del proveedor WNet en modo de usuario podría comunicarse directamente con un controlador redirector de red en modo kernel durante esta operación.
En Windows Server 2003, Windows XP y Windows 2000, las operaciones de archivos remotos que se realizan en una unidad asignada que no representa una unidad del sistema de archivos distribuido (DFS) no pasan por MUP. Estas operaciones van directamente al proveedor de red que controló la asignación de letras de unidad.
Para los redireccionadores de red que se ajustan al modelo de redirector de Windows Vista, MUP está implicado incluso cuando se usa una unidad de red asignada. Las operaciones de archivo realizadas en la unidad asignada pasan por MUP al redirector de red. Tenga en cuenta que, en este caso, MUP simplemente pasa la operación al redirector de red implicado.
El código de control de IOCTL_REDIR_QUERY_PATH se envía a los redireccionadores de red que se han registrado con MUP como proveedores de convención de nomenclatura universal (UNC) llamando a FsRtlRegisterUncProvider. Puede haber varios proveedores UNC registrados con MUP.
La operación de resolución de prefijo tiene dos propósitos:
La operación basada en nombres que dio lugar a la resolución de prefijos se enruta al proveedor que reclama el prefijo. Si se ejecuta correctamente, MUP garantiza que las operaciones posteriores basadas en identificadores (IRP_MJ_READ y IRP_MJ_WRITE, por ejemplo) vayan al mismo proveedor pasando completamente MUP.
El proveedor y el prefijo que afirmó se escriben en una caché de prefijos mantenida por MUP. Para las operaciones posteriores basadas en nombres, MUP usa esta caché de prefijos para determinar si un proveedor ya ha reclamado un prefijo antes de que MUP intente realizar una resolución de prefijo. Cada entrada de esta caché de prefijos está sujeta a un tiempo de espera (denominado TTL) una vez que se agrega a la memoria caché. Una entrada se desecha después de que expire este tiempo de espera, en cuyo momento, MUP volverá a realizar la resolución de prefijos para este prefijo en una operación posterior basada en nombres.
Código principal
IOCTL_REDIR_QUERY_PATH
Búfer de entrada
IrpSp:>Parameters.DeviceIoControl.Type3InputBuffer se establece en una estructura de datos QUERY_PATH_REQUEST que contiene la solicitud.
Longitud del búfer de entrada
Longitud del búfer de entrada, en bytes, que debe ser al menos sizeof(QUERY_PATH_REQUEST).
Búfer de salida
IRP:> UserBuffer se establece en una estructura de datos QUERY_PATH_RESPONSE que contiene la respuesta.
Longitud del búfer de salida
Longitud del búfer de salida, en bytes, que debe ser al menos sizeof(QUERY_PATH_RESPONSE).
Búfer de entrada y salida
n/a
Longitud del búfer de entrada y salida
n/a
Bloque de estado
El miembro estado de
| Código de estado | Significado |
|---|---|
| STATUS_BAD_NETWORK_NAME | No se encuentra el nombre del recurso compartido especificado en el servidor remoto. El nombre de equipo (\\server, por ejemplo) es válido, pero no se encuentra el nombre del recurso compartido especificado en el servidor remoto. |
| STATUS_BAD_NETWORK_PATH | No se puede encontrar la ruta de acceso de red. El nombre de la máquina (\\server, por ejemplo) no es válido o el redirector de red no puede resolver el nombre del equipo (con los mecanismos de resolución de nombres disponibles). |
| STATUS_INSUFFICIENT_RESOURCES | No había recursos suficientes disponibles para asignar memoria para los búferes. |
| STATUS_INVALID_DEVICE_REQUEST | Una solicitud de IOCTL_REDIR_QUERY_PATH_EX solo debe provenir de MUP y el requestorMode miembro de la estructura IRP siempre debe ser KernelMode. Este código de error se devuelve si el modo del solicitante del subproceso de llamada no se KernelMode. |
| STATUS_INVALID_PARAMETER | El miembro |
| STATUS_LOGON_FAILURE o STATUS_ACCESS_DENIED | Si se produjo un error en la operación de resolución de prefijos debido a credenciales no válidas o incorrectas, el proveedor debe devolver el código de error exacto devuelto por el servidor remoto; estos códigos de error no se deben traducir a STATUS_BAD_NETWORK_NAME ni STATUS_BAD_NETWORK_PATH. Códigos de error como STATUS_LOGON_FAILURE y STATUS_ACCESS_DENIED sirven como mecanismo de comentarios al usuario e indican el requisito de usar las credenciales adecuadas. Estos códigos de error también se usan en determinados casos para solicitar al usuario automáticamente las credenciales. Sin estos códigos de error, el usuario podría suponer que la máquina no es accesible. |
Si el redirector de red no puede resolver un prefijo, debe devolver un código NTSTATUS que coincida estrechamente con la semántica prevista de la lista anterior de códigos NTSTATUS recomendados. Un redirector de red no debe devolver el error encontrado real (STATUS_CONNECTION_REFUSED, por ejemplo) directamente a MUP si el código NTSTATUS no está de la lista anterior.
Observaciones
Los redireccionadores de red solo deben respetar los remitentes en modo kernel de este IOCTL, comprobando que Irp->RequestorMode es KernelMode.
Tenga en cuenta que IOCTL_REDIR_QUERY_PATH es un METHOD_NEITHER IOCTL. Esto significa que es posible que los búferes de entrada y salida no estén en la misma dirección. Un error común por parte de los proveedores UNC es suponer que el búfer de entrada y el búfer de salida son los mismos y usar el puntero del búfer de entrada para proporcionar la respuesta.
Cuando un proveedor UNC recibe una solicitud IOCTL_REDIR_QUERY_PATH, tiene que determinar si puede controlar la ruta de acceso UNC especificada en el FilePathName miembro de la estructura QUERY_PATH_REQUEST. Si es así, tiene que actualizar el miembro LengthAccepted de la estructura QUERY_PATH_RESPONSE con la longitud, en bytes, del prefijo que ha reclamado y completado el IRP con STATUS_SUCCESS. Si el proveedor no puede controlar la ruta de acceso UNC especificada, debe producir un error en la solicitud de IOCTL_REDIR_QUERY_PATH con un código de error NTSTATUS adecuado y no debe actualizar el miembro LengthAccepted de la estructura QUERY_PATH_RESPONSE. Los proveedores no deben modificar ninguno de los demás miembros ni la cadena FilePathName en ninguna condición.
La longitud del prefijo reclamado por el proveedor depende de un proveedor UNC individual. La mayoría de los proveedores suelen reclamar el nombredeservidor \\nombreservidor\sharename parte de una ruta de acceso del formulario \\nombreservidor\nombreDeServidor\ruta de acceso. Por ejemplo, si un proveedor reclama \\servidor\ pública dada una ruta de acceso \\servidor\\dir1\dir2, todas las operaciones basadas en nombres para el prefijo \\servidor\ público (\\servidor\archivo\público, por ejemplo) se enrutará automáticamente a ese proveedor sin ninguna resolución de prefijo porque el prefijo ya está en el memoria caché de prefijos. Sin embargo, una ruta de acceso con el prefijo \\servidor\marketing\presentación pasará por la resolución de prefijos.
Si un redirector de red reclama un nombre de servidor (\\servidor, por ejemplo), todas las solicitudes de recursos compartidos de este servidor irán a este redirector de red. Este comportamiento solo es aceptable si no hay ninguna posibilidad de que se acceda a otro recurso compartido en el mismo servidor al que accede un redirector de red diferente. Por ejemplo, un redirector de red que reclama \\servidor de una ruta de acceso UNC impedirá el acceso de otros redireccionadores a otros recursos compartidos de este servidor (el acceso de WebDAV a \\servidor\web, por ejemplo).
Para obtener más información, consulte los artículos siguientes:
compatibilidad de con nombres UNC y MUP
Requisitos
| Requisito | Valor |
|---|---|
| encabezado de |
ntifs.h (incluya Ntifs.h) |
Consulte también
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de