IOCTL_REDIR_QUERY_PATH IOCTL (ntifs.h)

  • [アーティクル]

IOCTL_REDIR_QUERY_PATH制御コードは、複数の UNC プロバイダー (MUP) によってネットワーク リダイレクターに送信され、名前ベースの操作 (通常はIRP_MJ_CREATE要求) で特定の UNC パスを処理できるプロバイダーを決定します。 この要求は"プレフィックス解決" と呼ばれます。

MUP は、UNC 名を使用するすべてのリモート ファイル システム アクセスを、リモート ファイル システム要求を処理できるネットワーク リダイレクター (UNC プロバイダー) にチャネル化するカーネル モード コンポーネントです。 コマンド ラインから実行できる次の例に示すように、UNC パスを使用する場合、MUP が関係します。

notepad \\server\public\readme.txt

マップされたドライブ文字 ("NET USE" コマンドなど) を作成する操作中、MUP は関与しません。 この操作は、ネットワーク リダイレクターの複数プロバイダー ルーター (MPR) とユーザー モードの WNet プロバイダー DLL によって処理されます。 ただし、ユーザー モード WNet プロバイダー DLL は、この操作中にカーネル モード ネットワーク リダイレクター ドライバーと直接通信する場合があります。

Windows Server 2003、Windows XP、および Windows 2000 では、分散ファイル システム (DFS) ドライブを表さないマップされたドライブで実行されるリモート ファイル操作は MUP を経由しません。 これらの操作は、ドライブ文字マッピングを処理したネットワーク プロバイダーに直接移動します。

Windows Vista リダイレクター モデルに準拠するネットワーク リダイレクターの場合、マップされたネットワーク ドライブが使用されている場合でも MUP が関係します。 マップされたドライブに対して実行されるファイル操作は、MUP を経由してネットワーク リダイレクターに移動します。 この場合、MUP は、関係するネットワーク リダイレクターに操作を渡すだけです。

IOCTL_REDIR_QUERY_PATH制御コードは、FsRtlRegisterUncProvider を呼び出すことによって、MUP に汎用名前付け規則 (UNC) プロバイダーとして登録されているネットワーク リダイレクターに送信されます。 MUP に登録されている UNC プロバイダーは複数あります。

プレフィックス解決操作には、次の 2 つの目的があります。

  • プレフィックス解決の結果として発生した名前ベースの操作は、プレフィックスを要求するプロバイダーにルーティングされます。 成功した場合、MUP では、後続のハンドル ベースの操作 (IRP_MJ_READやIRP_MJ_WRITEなど) が、完全に MUP をバイパスしている同じプロバイダーに確実に移動します。

  • プロバイダーと要求したプレフィックスは、MUP によって維持されるプレフィックス キャッシュに入力されます。 後続の名前ベースの操作では、MUP はこのプレフィックス キャッシュを使用して、MUP がプレフィックス解決の実行を試みる前に、プロバイダーが既にプレフィックスを要求しているかどうかを判断します。 このプレフィックス キャッシュ内の各エントリは、キャッシュに追加されるとタイムアウト (TTL と呼ばれます) の対象となります。 このタイムアウトが切れるとエントリが破棄されます。その時点で、MUP は後続の名前ベースの操作でこのプレフィックスに対してプレフィックス解決を再度実行します。

メジャー コード

IOCTL_REDIR_QUERY_PATH

[入力バッファー]

IrpSp->Parameters.DeviceIoControl.Type3InputBuffer は、要求を含む QUERY_PATH_REQUEST データ構造に設定されます。

入力バッファーの長さ

少なくとも sizeof(QUERY_PATH_REQUEST)である必要がある入力バッファーの長さ (バイト単位)。

出力バッファー

Irp->UserBuffer は、応答を含む QUERY_PATH_RESPONSE データ構造に設定されます。

出力バッファーの長さ

出力バッファーの長さ (バイト単位 sizeof(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はMETHOD_NEITHER IOCTL であることに注意してください。 これは、入力バッファーと出力バッファーが同じアドレスにない可能性があることを意味します。 UNC プロバイダーの一般的な間違いは、入力バッファーと出力バッファーが同じであると想定し、入力バッファー ポインターを使用して応答を提供することです。

UNC プロバイダーは、IOCTL_REDIR_QUERY_PATH要求を受信するときに、QUERY_PATH_REQUEST構造体の FilePathName メンバーで指定された UNC パスを処理できるかどうかを判断する 必要 があります。 その場合は、要求したプレフィックスの長さ (バイト単位) でQUERY_PATH_RESPONSE構造体の LengthAccepted メンバーを更新し、STATUS_SUCCESSで IRP を完了する必要があります。 プロバイダーが指定された UNC パスを処理できない場合は、適切な NTSTATUS エラー コードでIOCTL_REDIR_QUERY_PATH要求を失敗させ、QUERY_PATH_RESPONSE構造体の LengthAccepted メンバーを更新することはできません。 プロバイダーは、他のメンバーまたは FilePathName 文字列をいかなる条件でも変更することはできません。

プロバイダーによって要求されるプレフィックスの長さは、個々の UNC プロバイダーによって異なります。 ほとんどのプロバイダーは、通常、\\servername sharename\ パスという形式のパスの \\servername\共有名\の一部を要求します。 たとえば、プロバイダーが \\serverpublicdir1\dir2 というパスを指定して \\server\\public\ を要求した場合、プレフィックス \\serverpublic (\\server\\パブリック\ファイル 1 など) に対するすべての名前ベースの操作は、プレフィックスが既にプレフィックス キャッシュ内にあるため、プレフィックス解決なしでそのプロバイダーに自動的にルーティングされます。 ただし、プレフィックス \\server\マーケティング\プレゼンテーション を含むパスは、プレフィックス解決を通過します。

ネットワーク リダイレクターがサーバー名 (\\server など) を要求した場合、このサーバー上の共有に対するすべての要求はこのネットワーク リダイレクターに送信されます。 この動作は、同じサーバー上の別の共有が別のネットワーク リダイレクターによってアクセスされる可能性がない場合にのみ許容されます。 たとえば、UNC パスの \\server を要求するネットワーク リダイレクターは、このサーバー 上の他の共有 (たとえば、\\server\Web への WebDAV アクセス) への他のネットワーク リダイレクターによるアクセスを防ぎます。

詳細については、設計ガイドの以下のセクションを参照してください。

要件

要件 値
Header ntifs.h (Ntifs.h を含む)

こちらもご覧ください

FsRtlDeregisterUncProvider

FsRtlRegisterUncProvider

FsRtlRegisterUncProviderEx

IOCTL_REDIR_QUERY_PATH_EX