次の方法で共有


IOCTL_REDIR_QUERY_PATH IOCTL (ntifs.h)

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

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

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) プロバイダーとして登録されているネットワーク リダイレクターに送信されます。 複数の UNC プロバイダーが MUP に登録されている可能性があります。

プレフィックス解決操作には、次の 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)以上である必要があります。

入力/出力バッファー

n/a

入力/出力バッファーの長さ

n/a

状態ブロック

Status メンバーは、\\server\share プレフィックス名が認識された場合は成功した場合にSTATUS_SUCCESSに設定され、次のいずれかの適切な NTSTATUS 値に設定されます。

状態コード 意味
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 メンバーを更新し、IRP をSTATUS_SUCCESSで完了する必要があります。 プロバイダーが指定された UNC パスを処理できない場合は、適切な NTSTATUS エラー コードでIOCTL_REDIR_QUERY_PATH要求を失敗させる必要があり、QUERY_PATH_RESPONSE 構造体の LengthAccepted メンバーを更新しないでください。 プロバイダーは、他のメンバーまたは FilePathName 文字列をいかなる条件でも変更してはなりません。

プロバイダーによって要求されるプレフィックスの長さは、個々の UNC プロバイダーによって異なります。 ほとんどのプロバイダーは、通常、\\サーバー名sharename 形式のサーバー名sharenameパスのパスの一部要求します。 たとえば、次のようになります。 プロバイダーが \\サーバーパブリックサーバーパブリックdir1dir2を指定した場合、プレフィックス \\ に対するすべての名前ベースの操作サーバーパブリック (たとえば、パブリックfile1サーバー) は、プレフィックス解決なしで自動的にそのプロバイダーにルーティングされます。これは、プレフィックスが既にプレフィックス キャッシュ。 ただし、マーケティングプレゼンテーションプレフィックス \\サーバーのパスは、プレフィックス解決を経由します。

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

詳細については、次の記事を参照してください。

  • UNC 名前付けと MUP の サポート

  • Microsoft Windows Vista での MUP の変更の

必要条件

要件 価値
ヘッダー ntifs.h (Ntifs.h を含む)

関連項目

FsRtlDeregisterUncProvider の

FsRtlRegisterUncProvider

FsRtlRegisterUncProviderEx

IOCTL_REDIR_QUERY_PATH_EX