IOCTL_REDIR_QUERY_PATH_EX IOCTL (ntifs.h)

Artículo
02/27/2024

A partir de Windows Vista, el proveedor UNC (MUP) múltiple envía un código de control IOCTL_REDIR_QUERY_PATH_EX a los redireccionadores de red 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 mediante un nombre UNC a un redirector de red (el proveedor UNC) que es 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 puede 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 (el comando "NET USE", por ejemplo). 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 de WNet en modo de usuario puede comunicarse directamente con un controlador de redirector de red en modo kernel durante esta operación.

En el caso de 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_EX 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 FsRtlRegisterUncProviderEx. 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) pasen por MUP al mismo proveedor. Tenga en cuenta que este comportamiento es diferente para los redireccionadores de red que no cumplen el modelo de redirector de Windows Vista, que se enviará IOCTL_REDIR_QUERY_PATH para la resolución de prefijos. En el caso de los redireccionadores de red que no cumplen con el modelo de redirector de Windows Vista, MUP se omite completamente para las operaciones posteriores basadas en identificadores.
El proveedor y el prefijo que afirmó se escriben en una caché de prefijos mantenida por MUP. En el caso de las operaciones posteriores basadas en nombres, MUP usa esta memoria caché de prefijos para determinar si un proveedor ya ha reclamado un prefijo antes de que MUP intente realizar una resolución de prefijos. 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 descarta 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_EX

Búfer de entrada

IrpSp->Parameters.DeviceIoControl.Type3InputBuffer se establece en una estructura de datos QUERY_PATH_REQUEST_EX que contiene la solicitud.

Longitud del búfer de entrada

Tamaño de la estructura de QUERY_PATH_REQUEST_EX a la que apunta el búfer de entrada, en bytes.

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

Tamaño de la estructura QUERY_PATH_RESPONSE a la que apunta el búfer de salida, en bytes.

Búfer de entrada y salida

N/D

Longitud del búfer de entrada y salida

N/D

Bloque de estado

El miembro Status se establece en STATUS_SUCCESS si se reconoce el nombre de prefijo \\server\share o en un valor NTSTATUS adecuado, como uno de los siguientes:

status code	Significado
STATUS_BAD_NETWORK_NAME	No se encuentra el nombre del recurso compartido especificado en el servidor remoto. El nombre de la máquina (\\server, por ejemplo) es válido, pero no se encuentra el nombre de 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 miembro RequestorMode de la estructura IRP siempre debe ser KernelMode. Este código de error se devuelve si el modo solicitante del subproceso de llamada no era KernelMode.
STATUS_INVALID_PARAMETER	El miembro PathNameLength de la estructura QUERY_PATH_REQUEST supera la longitud máxima permitida, UNICODE_STRING_MAX_BYTES, para una cadena Unicode.
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 o STATUS_BAD_NETWORK_PATH. Los 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 detectado real (STATUS_CONNECTION_REFUSED, por ejemplo) directamente a MUP si el código NTSTATUS no está de la lista anterior.

Comentarios

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_EX es un IOCTL de METHOD_NEITHER. Esto significa que los búferes de entrada y salida podrían no estar 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 usan el puntero del búfer de entrada para proporcionar la respuesta.

Cuando un proveedor UNC recibe una solicitud de IOCTL_REDIR_QUERY_PATH_EX, tiene que determinar si puede controlar la ruta de acceso UNC especificada en el miembro PathName de la estructura QUERY_PATH_REQUEST_EX . Si es así, el proveedor UNC tiene que actualizar el miembro LengthAccepted de la estructura QUERY_PATH_RESPONSE con la longitud, en bytes, del prefijo que ha reclamado y completar 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_EX con un código de error NTSTATUS adecuado y no debe actualizar el miembro LengthAccepted de la estructura de QUERY_PATH_RESPONSE . Los proveedores no deben modificar ningún otro miembro ni el miembro PathName bajo 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 la partede sharename \\servername\ de una ruta de acceso del formulario \\servername\sharename\. Por ejemplo, si un proveedor reclama \\server\public dado una ruta de acceso \\server\public\dir1\dir2, todas las operaciones basadas en nombres para el prefijo \\server\public (\\server\public\file1) se enrutarán automáticamente a ese proveedor sin ninguna resolución de prefijos porque el prefijo ya está en la caché de prefijos. Sin embargo, una ruta de acceso con el prefijo \\presentación demarketing\del servidor\pasará por la resolución de prefijos.

Si un redirector de red reclama un nombre de servidor (\\server, 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 otro recurso compartido en el mismo servidor al que acceda un redirector de red diferente. Por ejemplo, un redirector de red que reclama \\server de una ruta de acceso UNC impedirá el acceso de otros redireccionadores a otros recursos compartidos de este servidor (acceso WebDAV a \\server\web, por ejemplo).

Para obtener más información, consulte las secciones siguientes en la Guía de diseño: