IOCTL_REDIR_QUERY_PATH_EX IOCTL (ntifs.h)
Windows Vista 以降、複数の UNC プロバイダー (MUP) は、 IOCTL_REDIR_QUERY_PATH_EX コントロール コードをネットワーク リダイレクターに送信して、名前ベースの操作 (通常はIRP_MJ_CREATE要求) で特定の UNC パスを処理できるプロバイダーを決定します。 この要求は"プレフィックス解決" と呼ばれます。
MUP は、UNC 名を使用してすべてのリモート ファイル システム アクセスを、リモート ファイル システム要求を処理できるネットワーク リダイレクター (UNC プロバイダー) にチャネリングするカーネル モード コンポーネントです。 MUP は、コマンド ラインから実行できる次の例に示すように UNC パスが使用される場合に関係します。
notepad \\server\public\readme.txt
マップされたドライブ文字 ("NET USE" コマンドなど) を作成する操作中、MUP は関係しません。 この操作は、ネットワーク リダイレクターの複数プロバイダー ルーター (MPR) とユーザー モード WNet プロバイダー DLL によって処理されます。 ただし、ユーザー モード WNet プロバイダー DLL は、この操作中にカーネル モード ネットワーク リダイレクター ドライバーと直接通信する可能性があります。
Windows Vista リダイレクター モデルに準拠するネットワーク リダイレクターの場合、マップされたネットワーク ドライブが使用されている場合でも MUP が関係します。 マップされたドライブで実行されるファイル操作は、MUP を経由してネットワーク リダイレクターに移動します。 この場合、MUP は関係するネットワーク リダイレクターに操作を渡すだけです。
IOCTL_REDIR_QUERY_PATH_EXコントロール コードは、FsRtlRegisterUncProviderEx を呼び出すことによって、MUP に汎用名前付け規則 (UNC) プロバイダーとして登録されているネットワーク リダイレクターに送信されます。 MUP に登録されている UNC プロバイダーは複数存在する可能性があります。
プレフィックス解決操作は、次の 2 つの目的で機能します。
プレフィックス解決の結果として発生した名前ベースの操作は、プレフィックスを要求するプロバイダーにルーティングされます。 成功した場合、MUP は後続のハンドルベースの操作 (IRP_MJ_READやIRP_MJ_WRITEなど) が MUP を経由して同じプロバイダーに移動することを保証します。 この動作は、プレフィックス解決のためにIOCTL_REDIR_QUERY_PATH送信される Windows Vista リダイレクター モデルに準拠していないネットワーク リダイレクターでは異なります。 Windows Vista リダイレクター モデルに準拠していないネットワーク リダイレクターの場合、後続のハンドル ベースの操作では MUP が完全にバイパスされます。
プロバイダーと要求したプレフィックスは、MUP によって管理されるプレフィックス キャッシュに入力されます。 後続の名前ベースの操作では、MUP はこのプレフィックス キャッシュを使用して、MUP がプレフィックス解決を実行する前にプロバイダーが既にプレフィックスを要求しているかどうかを判断します。 このプレフィックス キャッシュ内の各エントリは、キャッシュに追加されるとタイムアウト (TTL と呼ばれます) の影響を受けます。 このタイムアウトが切れるとエントリが破棄され、その時点で MUP は後続の名前ベースの操作でこのプレフィックスに対してプレフィックス解決を再度実行します。
メジャー コード
IOCTL_REDIR_QUERY_PATH_EX
[入力バッファー]
IrpSp->Parameters.DeviceIoControl.Type3InputBuffer は、要求を含む QUERY_PATH_REQUEST_EX データ構造に設定されます。
入力バッファーの長さ
入力バッファーが指す QUERY_PATH_REQUEST_EX 構造体のサイズ (バイト単位)。
出力バッファー
Irp->UserBuffer は、応答を含む QUERY_PATH_RESPONSE データ構造に設定されます。
出力バッファーの長さ
出力バッファーが指す QUERY_PATH_RESPONSE 構造体のサイズ (バイト単位)。
入力/出力バッファー
該当なし
入力/出力バッファーの長さ
該当なし
ステータス ブロック
Status メンバーは、\\server\share プレフィックス名が認識された場合に成功した場合はSTATUS_SUCCESSに設定され、次のいずれかの適切な NTSTATUS 値に設定されます。
| status code | 意味 |
|---|---|
| STATUS_BAD_NETWORK_NAME | 指定した共有名がリモート サーバーで見つかりません。 コンピューター名 (\\server など) は有効ですが、指定した共有名がリモート サーバーで見つかりません。 |
| STATUS_BAD_NETWORK_PATH | ネットワーク パスを見つけられない。 マシン名 (\\server など) が無効であるか、ネットワーク リダイレクターがコンピューター名を解決できません (使用可能な名前解決メカニズムを使用)。 |
| STATUS_INSUFFICIENT_RESOURCES | バッファーにメモリを割り当てるために使用できるリソースが不足していました。 |
| STATUS_INVALID_DEVICE_REQUEST | IOCTL_REDIR_QUERY_PATH_EX要求は MUP からのみであり、IRP 構造体の RequestorMode メンバーは常に KernelMode である必要があります。 呼び出し元スレッドのリクエスター モードが KernelMode でない場合、このエラー コードが返されます。 |
| STATUS_INVALID_PARAMETER | QUERY_PATH_REQUEST構造体の PathNameLength メンバーが、Unicode 文字列の最大許容長 (UNICODE_STRING_MAX_BYTES) を超えています。 |
| STATUS_LOGON_FAILUREまたはSTATUS_ACCESS_DENIED | 無効な資格情報または正しくない資格情報が原因でプレフィックス解決操作が失敗した場合、プロバイダーはリモート サーバーから返された正確なエラー コードを返す必要があります。これらのエラー コードは、STATUS_BAD_NETWORK_NAMEまたはSTATUS_BAD_NETWORK_PATHに変換することはできません。 STATUS_LOGON_FAILUREやSTATUS_ACCESS_DENIEDなどのエラー コードは、ユーザーへのフィードバック メカニズムとして機能し、適切な資格情報を使用する要件を示します。 これらのエラー コードは、ユーザーに資格情報の入力を自動的に求める場合にも使用されます。 これらのエラー コードがないと、ユーザーはマシンにアクセスできないと想定する場合があります。 |
ネットワーク リダイレクターがプレフィックスを解決できない場合は、上記の推奨 NTSTATUS コードの一覧から目的のセマンティクスと密接に一致する NTSTATUS コードを返す必要があります。 ネットワーク リダイレクターは、NTSTATUS コードが上記の一覧にない場合、実際に発生したエラー (たとえば、STATUS_CONNECTION_REFUSED) を直接 MUP に返す必要があります。
注釈
ネットワーク リダイレクターは、 Irp-RequestorMode> が KernelMode であることを確認することで、この IOCTL の カーネル モード送信者のみを優先する必要があります。
IOCTL_REDIR_QUERY_PATH_EXはMETHOD_NEITHER IOCTL であることに注意してください。 つまり、入力バッファーと出力バッファーが同じアドレスに存在しない可能性があります。 UNC プロバイダーの一般的な間違いは、入力バッファーと出力バッファーが同じであると想定し、入力バッファー ポインターを使用して応答を提供することです。
UNC プロバイダーは、IOCTL_REDIR_QUERY_PATH_EX要求を受信するときに、QUERY_PATH_REQUEST_EX構造体の PathName メンバーで指定された UNC パスを処理できるかどうかを判断する必要があります。 その場合、UNC プロバイダーは、要求したプレフィックスの長さ (バイト単位) でQUERY_PATH_RESPONSE構造体の LengthAccepted メンバーを更新し、STATUS_SUCCESSで IRP を完了する必要があります。 プロバイダーが指定された UNC パスを処理できない場合は、適切な NTSTATUS エラー コードでIOCTL_REDIR_QUERY_PATH_EX要求を失敗させ、QUERY_PATH_RESPONSE構造体の LengthAccepted メンバーを更新することはできません。 プロバイダーは、任意の条件で他のメンバーまたは PathName メンバーを変更することはできません。
プロバイダーによって要求されるプレフィックスの長さは、個々の UNC プロバイダーによって異なります。 ほとんどのプロバイダーは、通常、\\servername sharename\ パスという形式のパスの \\servername 共有名\\部分を要求します。 たとえば、プロバイダーが \\serverpublicdir1\dir2 パスを指定して \\server\\public\ を要求した場合、プレフィックス \\serverpublic (\\server\\public\file1 など) に対するすべての名前ベースの操作は、プレフィックスが既にプレフィックス キャッシュ内にあるため、プレフィックス解決なしでそのプロバイダーに自動的にルーティングされます。 ただし、プレフィックス \\server\マーケティング\プレゼンテーション を含むパスは、プレフィックス解決を経由します。
ネットワーク リダイレクターがサーバー名 (\\server など) を要求した場合、このサーバー上の共有に対するすべての要求はこのネットワーク リダイレクターに送信されます。 この動作は、同じサーバー上の別の共有が別のネットワーク リダイレクターによってアクセスされる可能性がない場合にのみ許容されます。 たとえば、UNC パスの \\server を要求するネットワーク リダイレクターは、このサーバー 上の他の共有への他のネットワーク リダイレクター (たとえば、\\server\Web への WebDAV アクセス) によるアクセスを妨げます。
詳細については、「デザイン ガイド」の以下のセクションを参照してください。
要件
| 要件 | 値 |
|---|---|
| サポートされている最小のクライアント | Windows Vista |
| Header | ntifs.h (Ntifs.h を含む) |