Azure NetApp Files でのパスの長さを理解する
ファイルとパスの長さとは、ディレクトリを含むファイル パスの Unicode 文字数のことです。 この制限の要因は、文字のバイト数によって決まる個々の文字の長さです。 たとえば、NFS と SMB では、255 バイトのパス コンポーネントが許容されます。 ASCII のファイル エンコード形式では 8 ビット エンコードが使われます。つまり、ASCII のファイル パス コンポーネント (ファイル名やフォルダー名など) では、ASCII 文字のサイズが 1 バイトであるため、最大 255 文字まで使用できます。
次の表は、Azure NetApp Files ボリュームでサポートされるコンポーネントとパスの長さを示したものです。
| コンポーネント | NFS | SMB |
|---|---|---|
| パス コンポーネントのサイズ | 255 バイト | 255 バイト |
| パスの長さのサイズ | 無制限 | 既定値: 255 バイト 最近の Windows バージョンでの最大値: 32,767 バイト |
| 横断時の最大パス サイズ | 4,096 バイト | 255 バイト |
Note
デュアル プロトコル ボリュームでは、最も小さい最大値が使われます。
SMB 共有名が \\SMB-SHARE である場合、各文字は 1 バイトであるため、共有名によってパスの長さに 11 Unicode 文字が追加されます。 特定のファイルへのパスが \\SMB-SHARE\apps\archive\file である場合は、29 Unicode 文字です。スラッシュを含めて、各文字は 1 バイトです。 NFS マウントの場合も、同じ概念が適用されます。 マウント パス /AzureNetAppFiles は、それぞれが 1 バイトの 17 Unicode 文字です。
Azure NetApp Files では、最新の Windows サーバーでサポートされている SMB 共有と同じパス長がサポートされます (最大 32,767 バイト)。 ただし、Windows クライアントのバージョンによっては、260 バイトより長いパスをサポートできないアプリケーションもあります。 個々のパス コンポーネント (スラッシュの間の値、ファイル名やフォルダー名など) では、最大 255 バイトがサポートされます。 たとえば、Azure NetApp Files のファイル パスでラテン語の大文字 "A" (1 文字あたり最大 1 バイト) を使うファイル名は、255 文字を超えることはできません。
# mkdir 256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
mkdir: cannot create directory ‘256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa’: File name too long
# mkdir 255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
# ls | grep 255
255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
文字サイズの識別
Linux ユーティリティ uniutils に文字インスタンスの複数のインスタンスを入力すると、byte フィールドの表示で Unicode 文字のバイト サイズを確認できます。
例 1: ラテン語の大文字 A は、使うたびに 1 バイトずつ増えます (0 から 255 の ASCII 文字範囲内にある 16 進値 41 を使用)。
# printf %b 'AAA' | uniname
character byte UTF-32 encoded as glyph name
0 0 000041 41 A LATIN CAPITAL LETTER A
1 1 000041 41 A LATIN CAPITAL LETTER A
2 2 000041 41 A LATIN CAPITAL LETTER A
結果 1: "AAA" という名前は、255 バイトのうち 3 バイトを使います。
例 2: 日本語の文字 "字" は、インスタンスごとに 3 バイトずつ増えます。 これは、encoded as フィールドの下にある 3 つの個別の 16 進コード値 (E5、AD、97) でも計算できます。 各 16 進値は 1 バイトを表します。
# printf %b '字字字' | uniname
character byte UTF-32 encoded as glyph name
0 0 005B57 E5 AD 97 字 CJK character Nelson 1281
1 3 005B57 E5 AD 97 字 CJK character Nelson 1281
2 6 005B57 E5 AD 97 字 CJK character Nelson 1281
結果 2: "字字字" という名前のファイルは、255 バイトのうち 9 バイトを使います。
例 3: 分音符号付きの文字 Ä は、インスタンスあたり 2 バイト (C3 + 84) を使います。
# printf %b 'ÄÄÄ' | uniname
character byte UTF-32 encoded as glyph name
0 0 0000C4 C3 84 Ä LATIN CAPITAL LETTER A WITH DIAERESIS
1 2 0000C4 C3 84 Ä LATIN CAPITAL LETTER A WITH DIAERESIS
2 4 0000C4 C3 84 Ä LATIN CAPITAL LETTER A WITH DIAERESIS
結果 3: "ÄÄÄ" という名前のファイルは、255 バイトのうち 6 バイトを使います。
例 4: 😃 絵文字などの特殊文字は、Unicode 文字に使われる 0 から 3 バイトを超える未定義の範囲に分類されます。 その結果、その文字エンコードにはサロゲート ペアが使われます。 この場合、文字の各インスタンスは 4 バイトを使います。
# printf %b '😃😃😃' | uniname
character byte UTF-32 encoded as glyph name
0 0 01F603 F0 9F 98 83 😃 Character in undefined range
1 4 01F603 F0 9F 98 83 😃 Character in undefined range
2 8 01F603 F0 9F 98 83 😃 Character in undefined range
結果 4: "😃😃😃" という名前のファイルは、255 バイトのうち 12 バイトを使います。
ほとんどの絵文字は 4 バイトの範囲に分類されますが、最大 7 バイトにまでなる可能性があります。 1,000 を超える標準絵文字のうち、約 180 個は Basic Multilingual Plane (BMP) に含まれます。つまり、クライアントによる言語の種類のサポートに応じて、Azure NetApp Files でテキストまたは絵文字として表示できます。
BMP や他の Unicode プレーンについて詳しくは、「Azure NetApp Files でのボリューム言語について理解する」をご覧ください。
パスの長さに対する文字バイトの影響
パスの長さはファイル名またはフォルダー名の文字数と考えられていますが、実際にはパスでサポートされるバイトの "サイズ" です。 各文字によって名前にバイト サイズが追加されるため、異なる言語の異なる文字セットでは、サポートされるファイル名の長さが異なります。
以下のようなシナリオが考えられます。
ファイルまたはフォルダーのファイル名は、アルファベット "A" の繰り返しです。 (例: AAAAAAAA)
"A" は 1 バイトを使い、255 バイトがパス コンポーネントのサイズ制限であるため、ファイル名では "A" のインスタンスを 255 個使用できます。
ファイルまたはフォルダーの名前は、日本語の文字 "字" の繰り返しです。
"字"のサイズは 3 バイトなので、ファイル名の長さの制限は "字"のインスタンス 85 個 (3 バイト * 85 = 255 バイト)、つまり合計 85 文字になります。
ファイルまたはフォルダーの名前は、笑顔の絵文字 (😃) の繰り返しです。
笑顔の絵文字 (😃) は 4 バイトを使うので、その絵文字のみを含むファイル名は、合計 64 文字 (255 バイト/4 バイト) まで許されます。
- ファイルまたはフォルダーは、異なる文字の組み合わせを使います (例: Name字😃)。
異なるバイト サイズの異なる文字がファイル名またはフォルダー名で使われている場合は、各文字のバイト サイズがファイルまたはフォルダーの長さに影響します。 "Name字😃" というファイル名またはフォルダー名は、合計 255 バイトの長さのうち 1+1+1+1+3+4 バイト (11 バイト) を使います。
特別な絵文字の概念
BMP の分類には、フラグ絵文字などの特別な絵文字が存在します。絵文字は、クライアントのサポートに応じて、テキストまたは画像としてレンダリングされます。 クライアントが画像の指定をサポートしていない場合、代わりに地域のテキスト ベースの指定が使われます。
たとえば、米国フラグでは、文字 "us" が使われます (これはラテン文字 U+S に似ていますが、実際には異なるエンコードを使う特殊文字です)。 Uniname では、文字間の違いが示されます。
# printf %b 'US' | uniname
character byte UTF-32 encoded as glyph name
0 0 000055 55 U LATIN CAPITAL LETTER U
1 1 000053 53 S LATIN CAPITAL LETTER S
# printf %b '🇺🇸' | uniname
character byte UTF-32 encoded as glyph name
0 0 01F1FA F0 9F 87 BA 🇺 Character in undefined range
1 4 01F1F8 F0 9F 87 B8 🇸 Character in undefined range
フラグ絵文字に対して指定された文字は、サポートされているシステムではフラグ画像に変換されますが、サポートされていないシステムではテキスト値のままになります。 これらの文字では 1 文字につき 4 バイトが使われ、フラグ絵文字が使われると合計 8 バイトになります。 そのため、ファイル名では合計 31 個のフラグ絵文字を使用できます (255 バイト/8 バイト)。
SMB パスの制限
既定では、Windows のサーバーとクライアントは最大 260 バイトのパス長をサポートしますが、<NUL> 値やドメイン情報などのメタデータが Windows パスに追加されるため、実際のファイル パスの長さはそれより短くなります。
Windows でパスの制限を超えると、次のダイアログ ボックスが表示されます。
「パスの最大長の制限」で説明されているように、Windows 10 または Windows Server 2016 バージョン 1607 以降を使っている場合は、レジストリ値を変更して、SMB パスの長さを拡張できます。 この値を変更すると、パスの長さを最大 32,767 バイトまで拡張できます (メタデータを引いた値)。
この機能を有効にしたら、SMB 共有にアクセスするには、長くなったパス長に対応するため、パスで \\?\ を使う必要があります。 この方法は UNC パスをサポートしていないため、SMB 共有をドライブ文字にマップする必要があります。
代わりに \\?\Z: を使ってアクセスでき、より長いファイル パスがサポートされます。
Note
現在、Windows CMD では \\?\ の使用はサポートされていません。
最大パス長を増やすことができない場合の回避策
Windows 環境でパスの最大長を有効にできない場合、または Windows クライアントのバージョンが低すぎる場合は、回避策があります。 SMB 共有をディレクトリ構造の深い場所にマウントすると、クエリされるパスの長さを減らすことができます。
たとえば、\\NAS-SHARE\AzureNetAppFiles を Z: にマップするのではなく、\\NAS-SHARE\AzureNetAppFiles\folder1\folder2\folder3\folder4 を Z: にマップします。
NFS パスの制限
Azure NetApp Files ボリュームでの NFS パスには、個々のパス コンポーネントに対して同じ 255 バイトの制限があります。 ただし、各コンポーネントは一度に 1 つずつ評価され、要求ごとに最大 4,096 バイトを処理できるため、合計のパスの長さはほぼ無制限です。 たとえば、各パス コンポーネントが 255 バイトの場合、NFS クライアントは要求ごとに最大 15 個のコンポーネントを評価できます (/ 文字を含む)。 そのため、4,096 バイトの制限を超えるパスに対する cd 要求では、"ファイル名が長すぎます" というエラー メッセージが発生します。
ほとんどの場合、Unicode 文字は 1 バイト以下であるため、4,096 バイトの制限は 4,096 文字に相当します。 文字のサイズが 1 バイトを超える場合、パスの長さは 4,096 文字未満になります。 サイズが 1 バイトを超える文字は、1 バイト文字より合計文字数に大きな影響を与えます。
パスの長さの最大値は、getconf PATH_MAX /NFSmountpoint コマンドを使って照会できます。
Note
この制限は、NFS クライアントの limits.h ファイルで定義されています。 これらの制限は調整しないでください。
デュアル プロトコル ボリュームに関する考慮事項
デュアル プロトコル アクセスに Azure NetApp Files を使った場合、NFS プロトコルと SMB プロトコルでのパスの長さの処理方法の違いにより、ファイルやフォルダーの間で互換性がなくなる可能性があります。 たとえば、Windows SMB ではパスは最大 32,767 文字までサポートされますが (SMB クライアントで長いパス機能が有効になっている場合)、NFS のサポートではその長さを超える可能性があります。 そのため、NFS で作成されたパスが SMB でサポートされる長さを超える場合、パスの長さの最大値に達すると、クライアントはデータにアクセスできません。 このような場合は、ファイル名とフォルダー名 (およびフォルダー パスの深さ) を作成するときに、プロトコル間でファイル パスの長さの上限が小さい方を考慮するか、SMB 共有を目的のフォルダー パスに近づけてマップして、パスの長さを減らします。
SMB 共有をボリュームの最上位レベルにマップして \\share\folder1\folder2\folder3\folder4 のパスを下方に移動する代わりに、SMB 共有を \\share\folder1\folder2\folder3\folder4 のパス全体にマップすることを検討します。 その結果、Z: へのドライブ文字のマッピングは目的のフォルダーに配置され、パスの長さが Z:\folder1\folder2\folder3\folder4\file から Z:\file に短縮されます。
特殊文字に関する考慮事項
Azure NetApp Files ボリュームで使われる C.UTF-8 の言語タイプは、ドイツ語、キリル語、ヘブライ語、およびほとんどの中国語、日本語、韓国語 (CJK) を含む、多くの国と言語をカバーしています。 Unicode の最も一般的なテキスト文字は 3 バイト以下です。 絵文字、音楽記号、数学記号などの特殊文字は、多くの場合、3 バイトを超えています。 UTF-16 サロゲート ペア ロジックを使うものもあります。
Azure NetApp Files でサポートされていない文字を使うと、別のファイル名を要求する警告が表示されることがあります。
このエラーは、名前が長すぎるのではなく、実際には、Azure NetApp Files ボリュームで SMB に使うには文字バイト サイズが大きすぎることが原因で発生します。 Azure NetApp Files には、この制限に対する回避策はありません。 Azure NetApp Files での特殊文字の処理について詳しくは、「特殊文字セットでのプロトコルの動作」をご覧ください。