30

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

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

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

C:\Documents and Settings\Bill\Some Stupid FOlder Name\A really ridiculously long file thats really very very very..........very long.pdf

全長 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 ルールに違反するファイルをどのように作成できますか?

4

8 に答える 8

11

それは本当の問題ではありません。NTFS は最大32K ( 32,767 ワイド文字) のファイル名をサポートします。正しい API とファイル名の正しい構文のみを使用する必要があります。基本ルールは次のとおりです。ファイル名は で始まる必要があります'\\?\'( http://msdn.microsoft.com/en-us/library/aa365247(v=VS.85).aspxを参照) like \\?\C:\Temp. UNC で使用できるのと同じ構文: \\?\UNC\Server\share\Path. API 関数の小さなサブセットしか使用できないことを理解することが重要です。たとえば、関数の MSDN の説明を見てください。

CreateFile
CreateDirectory 
MoveFile

等々

次のようなテキストが見つかります。

この関数の ANSI バージョンでは、名前は MAX_PATH 文字に制限されています。この制限を 32,767 ワイド文字に拡張するには、関数の Unicode バージョンを呼び出し、パスの先頭に "\?\" を追加します。詳細については、ファイルの命名を参照してください。

安心してご利用いただける機能です。からのファイル ハンドルを持っている場合は、使用CreateFileされる他のすべての関数hFile(など) を制限なく使用できます。ReadFileWriteFile

ウイルス スキャナ、バックアップ ソフトウェア、またはサーバー上で動作する優れたソフトウェアなどのプログラムを作成する場合は、すべてのファイル操作で最大32K文字のファイル名をサポートし、文字ではサポートしないようにプログラムを作成する必要がありますMAX_PATH。

于 2010-05-13T10:05:49.967 に答える
10

この制限は、C または C++ で記述された多くのソフトウェアに組み込まれています。MSFT コードを含みますが、彼らはそれを削り取っています。これは Win32 の制限の一部にすぎません。たとえば、WIN32_FIND_DATA を介したファイル名 (パスではない) の長さにはまだ厳しい上限があります。.NET にも長さの制限がある理由の 1 つ。これがすぐになくなるわけではありません。Win32 は依然として強力であり、石器時代の C ストリングが消えることはありません。

おそらく、同じように失敗する別のプログラムを顧客に見せるまでは、おそらく顧客はほとんど同情しないでしょう。ただし、コードが文字列バッファ オーバーフローの可能性を確実に検出できることを確認してから、適切な診断を行ってください。ヒープの破損を爆撃するプログラムには同情しません。

于 2010-05-13T11:57:03.390 に答える
6

あなたが言及したように、Windows シェル関数の多くは MAX_PATH までのパスでしか機能しません。Windows XP と Vista では、長いファイル名を持つディレクトリをネストするときに Explorer で問題が発生すると思います。私は Windows 7 をチェックしていません。おそらく、Windows 7 が修正したのでしょう。残念ながら、これはユーザーがこれらのファイルを閲覧するのに苦労していることを意味します.

本当に長いパスをサポートしたい場合は、Shell32.dll で使用している、パスを取るすべての関数をチェックして、それらが長いパスをサポートしていることを確認する必要があります。そうでないものについては、Kernel32 関数を使用して自分で作成する必要があります。

Shell32 を使用し、MAX_PATH に制限することにした場合は、長いファイル パスをサポートするようにコードを記述することをお勧めします。Microsoft が後で Shell32 を変更する (または代替を作成する) 場合、それらのサポートを追加するためのより良い位置に立つことができます。

問題にさらにいくつかの次元を追加するために、ファイル名は UTF-16 であり、大文字と小文字を区別する可能性のある非 NTFS または FAT ファイルシステムに遭遇する可能性があることを覚えておいてください!

于 2010-05-14T02:13:24.477 に答える
5

独自の API では、パスの長さの固定制限 (またはその他のハード制限) をハードコーディングしないでください。ただし、何らかのタスクを実行するために、システム API の前提条件に違反するべきではありません。Windows がパス名の長さを制限しているという事実はばかげており、バグと見なす必要があります。そうは言っても、最大パス長の制限などの特定の望ましくない動作が発生したとしても、文書化されている以外のさまざまなシステム API を使用しないことをお勧めします。要するに、あなたの見解は完全に公正です。OS がサポートしていない場合、OS はサポートしていません。とはいえ、これは Windows の制限であり、独自のコードの制限ではないことをユーザーに明確にする必要があります。

于 2010-05-13T09:54:07.910 に答える
2

MAX_PATH よりも長いパスをサポートしていないソフトウェアでも、長いパスを持つこれらのファイルを作成する簡単な方法の 1 つは、ファイル共有を使用することです。

例：

「C:\My veeeeeeeeeeeeeeeeeeeeery looooooooooooooong フォルダー」は「データ」として共有できます。その後、ユーザーは、UNC パス \\computer\data を介して、または (さらに短い) ドライブ文字 (M:\) を介して、M: が \\computer\data にマップされていると仮定して、そのフォルダーにアクセスできます。

これは、ファイル サーバーでよく発生します。

于 2011-01-12T12:39:59.823 に答える
1

私はいくつかのCプログラミングをしていて、特定のファイル名の最大長を取得する方法を探していました.MAX_PATHを検索した後、このスレッドに出くわし、この問題についていくつか考えた後、このスレッドのコメントを読んだ後、私は持っています以下の結論に至ります。

したがって、NTFSは最大32.767文字の長さのファイル名をサポートしていることを理解していますが、知識によれば、FAT16は8 + 3の11文字のファイル名しかサポートしていないため、実際にはオペレーティングシステムには、プログラムが最大ファイル名サイズを決定するために呼び出すことができる関数が必要です。 、単純にすべてのファイル システムには、ファイル名の長さを含むさまざまな制限があるためです。

したがって、最終的な結論は、私たち開発者はデータがどのファイルシステムに保存されるかについて何も知らないため、唯一の解決策は試行錯誤の方法でなければならないということです。

于 2013-07-07T17:48:38.260 に答える
1

多くの場合、パスは 260 よりも大きくなる可能性があります。1 つの例は、シンボリック リンクがネストされ、時には意図的に何度も繰り返される場合です。プログラマーは、プログラムでこれらの非常に大きなパスを処理する必要があるかどうかを検討する必要があると思います。IMO、260には十分なスペースがありますが、それは私だけです. これに対する私の答えは次のとおりです。

260 文字の制限を破ることについて深く自問する必要がある場合は、おそらくそれがあなたがすべきことです。よくわからないことをしようとするとき、私たちはしばしば確認を求めます...

API 内の最大パスの長さは約 32k だと思いますが、それはあなた次第です。昔はかなり大きな変化でした (メモリ セグメント全体の半分!! おいおい!) が、今日、私たちが住んでいるセグメント トランスペアレント アドレッシング環境では、すべてのメモリが 32k のフラットに積み上げられています。ない...私の知る限り、他の多くの文字を必要とする派手なユニコード言語などを使用していない限り、パスはそれほど長くする必要はありません. これが役立つことを願っています.....または痛いですか？

于 2012-09-25T04:26:25.593 に答える
0

特定の質問に対する厳密な回答ではありませんが、長いファイル名を処理する必要がある人には役立つかもしれません。

Delimon ライブラリは、長いファイル名の問題を解決するための Microsoft TechNet の .NET Framework 4 ベースのライブラリです。

Delimon.Win32.IO ライブラリ (V4.0) .

System.IO の主要なメソッドの独自のバージョンがあります。たとえば、次のように置き換えます。

System.IO.Directory.GetFiles

と

Delimon.Win32.IO.Directory.GetFiles

これにより、長いファイルとフォルダーを処理できます。

ウェブサイトから：

Delimon.Win32.IO は、System.IO の基本的なファイル機能を置き換え、最大 32,767 文字のファイルとフォルダ名をサポートします。

このライブラリは .NET Framework 4.0 で作成されており、x86 および x64 システムで使用できます。標準の System.IO 名前空間のファイルとフォルダーの制限は、ファイル名が 260 文字、フォルダー名が 240 文字のファイルで機能します (通常、MAX_PATH は 260 文字として構成されます)。通常、標準 .NET ライブラリで System.IO.PathTooLongException エラーが発生します。

于 2013-02-16T06:15:02.437 に答える