IOCTL_REDIR_QUERY_PATH_EX IOCTL (ntifs.h)
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) 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.
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_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 con 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 que no se ajustan al 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. 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 produce 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 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/a
Longitud del búfer de entrada y salida
n/a
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:
| 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_EX 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 de IOCTL_REDIR_QUERY_PATH_EX, tiene que determinar si puede controlar la ruta de acceso UNC especificada en el PathName miembro 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 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_EX 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 ningún otro miembro ni el PathName miembro 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 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 las secciones siguientes en la Guía de diseño:
compatibilidad de con nombres UNC y MUP
Requisitos
| Requisito | Valor |
|---|---|
| cliente mínimo admitido | Windows Vista |
| encabezado de |
ntifs.h (incluya Ntifs.h) |