問題タブ [max-path]

CreateProcess または CreateProcessW のいずれかを取得して、名前が MAX_PATH 文字未満のプロセスを実行しようとしていますが、パスは MAX_PATH 文字を超えています。ドキュメントによると：http://msdn.microsoft.com/en-us/library/ms682425.aspx、lpApplicationName が NULL でないことを確認する必要があり、lpCommandLine は最大 32,768 文字です。

試してみましたが、ERROR_PATH_NOT_FOUND が発生します。

CreateProcessW に変更しましたが、それでも同じエラーが発生します。で説明されているように、lpApplicationName の前に \\?\ を付けると、http://msdn.microsoft.com/en-us/library/aa365247(VS.85).aspx CreateProcessW を呼び出すと、別のエラーが表示され、もう少し近づいたと思われます: ERROR_SXS_CANT_GEN_ACTCTX。

CreateProcessW への私の呼び出しは次のとおりです。

CreateProcessW(w_argv0,arg_string,NULL,NULL,0,NULL,NULL,&si,&ipi);

w_argv0 はどこにありますか\\?\<long absolute path>\foo.exe.

arg_string には、"<長い絶対パス>\foo.exe" foo が含まれています

si は次のように設定されます。

次のように、pi は空です。

システム イベント ログを調べたところ、イベント ID 59、ソース SideBySide: Generate Activation Context failed for .Manifest でこれを試行するたびに新しいエントリがあります。参照エラー メッセージ: 操作は正常に完了しました。

実行しようとしているファイルは、パス < MAX_PATH 文字で正常に実行されます。

明確にするために、<長い絶対パス> の 1 つのコンポーネントが MAX_PATH 文字を超えることはありません。最後に .manifest があっても、実行可能ファイル自体の名前は確かにそうではありません。ただし、パス全体を合わせると、長さが MAX_PATH 文字を超えています。

マニフェストを埋め込むかどうかに関係なく、同じエラーが発生します。マニフェストは foo.exe.manifest という名前で、埋め込まれていない場合は実行可能ファイルと同じディレクトリに存在します。を含む：

これを機能させる方法を知っている人はいますか？おそらく：

• CreateProcess または CreateProcessW を呼び出してパス > MAX_PATH 文字でプロセスを実行する別の方法

• マニフェスト ファイルでできること

XP SP2 で Visual Studio 2005 を使用してビルドし、ネイティブで実行しています。

ご協力いただきありがとうございます。

ASP.NET に関する問題を発見しましたが、少なくとも 1 人は困惑させられました。HttpModule を使用して、Web アプリケーションへのワイルドカード リクエストを処理しようとしていました。生成された URL は動的で、数百文字になる可能性があります。残念ながら、aspnet_isapi.dll ファイルには、URL のパスの長さを 260 文字にハードコードされた MAX_PATH に制限する制限があるようです。

他の誰かがこれに遭遇し、この制限を回避する方法を見つけましたか? クエリ文字列パラメーターはオプションではありません。

ありがとう、グレッグ・バラード

Unicode ファイル名が指定されたファイルを開くための ac ライブラリに出会いました。ファイルを開く前に、まず "\\?\" を先頭に追加してファイル名をパスに変換します。この msdn articleに従って、パスで許可される最大文字数を増やす以外にこれを行う理由はありますか?

これらの「\\?\」パスには、Windows API と標準ライブラリの Unicode バージョンが必要なようです。

バックグラウンド

あるサーバーから別のサーバーにネットワーク経由でファイルを移行するには、最大で .NET バージョン 2.0 を使用するツールを作成する必要があります (このクライアントでは、政治的、商業的、および機密性/信頼上の理由から、市販のものを使用することはできません)。サーバーはローカル チーム用のファイル サーバーであり、再編成を容易にするために、特定のチーム フォルダーを他のサーバーに移行する必要があります。基本的な考え方は、各ファイルを読み取り、数時間のうちにネットワーク経由でストリーミングし、数日後にデータが移行されるというものです。ファイルのアクセス許可を保持する必要があります。これには数日かかるため (一部のチームでは最大で数ギガバイトのデータについて話している)、毎晩ファイルを繰り返し処理し、変更日を比較して、変更された日付を更新する必要があります。理論的には、最終的に新しいサーバーにはファイルの最新のコピーがあり、ユーザーは新しいサーバーに切り替えることができます。もちろん、これほど単純ではありませんが、機能すると思われる設計があります:)

問題

理論的には、ファイルを開いてネットワーク経由でストリーミングし、反対側で書き込むだけですよね? :)

残念ながら、サーバー自体では、ファイル共有は次のようなフォルダー パスに作成されました。

D:\Data\Team Shares\DIVISION\DEPARTMENT\NAME OF TEAM - かなり長い可能性があります\

ユーザーごとに、このパスはドライブにマップされます。たとえば、\\SERVER\TEAMNAME として共有され、T: ドライブにマップされます。

これにより、T: ドライブから表示されるファイルがMAX_PATH制限内にあるという状況が発生しましたが、サーバー自体でローカルに表示すると、制限をはるかに超えてしまいます。ネットワーク共有を使用してファイルにアクセスすることはできません。このツールは、何百ものこれらのサーバーで実行するために汎用的である必要があり、どのファイル共有が移動する必要があるか、そうでないかを判断する標準的な方法がないためです。命名規則標準すらありません。また、たまに他のシェアのサブシェアもあり、MAX_PATH制限を2倍オーバー！

「\\?\」プレフィックスを使用してパスを指定する回避策を認識しています。これにより、パスが UNC パスとして扱われ、理論上の最大文字数は 32k 文字になります。

この回避策は Win32 API レベルで実装されています。System.IO 名前空間は (ほとんどの場合) 基本的にネイティブの Win32 API 関数の薄いラッパーにすぎませんが、Microsoft は呼び出しを API に渡す前に追加の (間違った) 検証を「役立つように」実装しています。 . この場合、.NET Framework はパスを拒否しています。は無効なパス文字です。

だから私の質問は...私が考えていなかった方法で、System.IO名前空間のほぼ全体を完全に書き直し、P/Invoke呼び出しを大量に行うことなく、これを回避できる方法はありますか?この厄介な検証を削除しますか?

ASP.NET 3.5、IIS7

Global.asaxのApplication_BeginRequestで、クエリ文字列を使用せずに、リクエストのURLから埋め込まれている完全に別個のURLを抽出する必要があります。

私が思いついた解決策は、次のように、ターゲットURL全体をディレクトリであるかのように16進エンコードすることでした。

http://localhost/687474703A...etc...732E6D7033/irrelevantFilename.txt

これは、 ASP.NET実装が260文字を超えるURLパスを許容しないIIS7では失敗します。

私のコードは、リクエストURLの生成方法と、そこにターゲットURLを埋め込む方法を制御しますが、そのターゲットURL値（サードパーティのURL）を制御することはできません。

このターゲットURLをリクエストURLにどの程度うまく埋め込むことができますか？

興味深い事例がありました。

私のソフトウェアは、パスが MAX_PATH よりも長いために発生した障害を報告しました。

パスは、マイ ドキュメント内の単純な古いドキュメントでした。たとえば、次のようになります。

全長 269 文字 (MAX_PATH==260)。

ユーザーは外付けハード ドライブなどを使用していませんでした。これは、Windows 管理ドライブ上のファイルでした。

だから私の質問はこれです。気にする必要がありますか？

長いパスを処理できると言っているのではなく、処理すべきかどうかを尋ねているのです。はい、一部の Win32 API での "\?\" Unicode ハックを認識していますが、このハックにはリスクがないわけではないようです ( API がパスを解析する方法の動作を変更しています)。また、すべての API でサポートされているわけではありません。

とにかく、私の立場/主張を述べさせてください：

1. まずおそらく、ユーザーがこの制限を破ることができた唯一の方法は、彼女が使用したアプリが特別な Unicode ハックを使用している場合です。これは PDF ファイルなので、彼女が使用した PDF ツールがこのハックを使用している可能性があります。
2. これを（ユニコードハックを使用して）再現しようとし、実験しました。私が見つけたのは、ファイルはエクスプローラーに表示されますが、何もできないということです。開けません、「プロパティ」を選択できません（Windows 7）。他の一般的なアプリ (IE、Firefox、メモ帳など) ではファイルを開くことができません。エクスプローラーでは、長すぎるファイル/ディレクトリを作成することもできません。単に拒否されます。コマンド ライン ツール cmd.exe についても同様です。

したがって、基本的には、次のように考えることができます。ルージュ ツールにより、ユーザーは、多くの Windows (エクスプローラーなど) からアクセスできないファイルを作成できます。私はこれに対処する必要はないという見方をすることができました。

(余談ですが、これは短い最大パス長の承認投票ではありません。260 文字は冗談だと思います。Windows シェルと一部の API が 260 を超える文字を処理できない場合、なぜ?)。

それで、これは公正な見方ですか？「私の問題ではない」と言うべきですか？

更新:同じ問題を抱えている別のユーザーがいます。今回はmp3ファイルです。何か不足していますか？これらのユーザーは、MAX_PATH ルールに違反するファイルをどのように作成できますか?

Windowsアプリケーションでより長いファイルパスを処理することを検討しています。

現在、ユーザーがファイルの絶対パスを入力できるテキストボックス（編集ボックス）があります。次に、その型指定されたファイルパスを、を使用してGetWindowText、次のように宣言された文字列に読み込みます。TCHAR FilePath[MAX_PATH];

MAX_PATH明らかに、ここで私は260文字に制限する定数に依存しています。したがって、より長いファイル/パス名を処理するには、TCHAR配列を次のように拡張できますTCHAR FilePath[32767];。

それとももっと良い方法はありますか？可変長配列を使用できますか？（TCHAR FilePath[];これはC ++でも可能ですか？-申し訳ありませんが、これはかなり新しいです）。

よろしくお願いします！

これが私が上で述べたものの全体のコードスニペットです：

Boost.Filesystemライブラリを使用して、パス、ファイル、およびディレクトリを操作したいと思います。私の質問は、MAX_PATHよりも長いパスがサポートされているかどうかです。

Win32APIには回避策「\\？」があることは知っていますが、PathAppendやPathCombineなどの基本的な関数ではサポートされていません。

だから私はMAX_PATHとBoost.FSについての有用な情報を探しています。

ありがとう

UPD：パスの追加、パスの結合などのすべての操作に注意します（Win32APIにはこれらの関数がありますが、MAX_PATHより長いパスでは機能しません）。たとえば、CreateFileWとDeleteFileWはどちらもMAX_PATHより長いパスをサポートします。Boost.FSは、shlwapiやshell32に見られるような、長いパスをサポートしないことが多いWin32APIユーティリティ関数の代わりになる可能性があります

重複の可能性:
Windows に 260 文字のパスの長さの制限があるのはなぜですか?

私は、この恐ろしい 260 文字の完全修飾パス制限を回避する方法を見つけようとしていますが、同時に、そもそもなぜパス制限があるのだろうか!? 260 が「多い」ように見える人もいることは知っていますが、この問題に遭遇して以来、実際にはそうではありません。

基本的に:
なぜ文字数制限が必要なのですか?
どうやってそれを回避しますか？

WinRTでのファイルシステムアクセスが異なることは知っていますが（読み取り：分離）、それでもMAX_PATHについて心配する必要があるのか​​、それともその制限が回避されているのか知りたいですか？