Azure NetApp Files でのパスの長さを理解する

ファイルとパスの長さは、ディレクトリを含むファイル パスで許可される Unicode 文字の数を指します。 Azure NetApp Files では、NFS プロトコルと SMB プロトコルの動作は、ファイル名とフォルダー名の文字の処理方法で多少異なります。

• NFS では、文字バイト サイズはパスの長さに関する重要な要素です。
• SMB では文字バイト サイズはあまり重要ではありませんが、パスの長さは、クライアントの構成方法と SMB 共有の接続方法によって影響を受ける可能性があります。

次の表は、Azure NetApp Files ボリュームでサポートされるコンポーネントとパスの長さを示したものです。

Azure NetApp Files での NFS パスの長さの考慮事項

Azure NetApp Files NFS ボリュームでは、文字バイト サイズが個々のパスの長さの要因になります。 たとえば、NFS では、最大サイズが 255 バイトのパス コンポーネントが許可されます。 American Standard Code for Information Interchange (ASCII) のファイル エンコード形式では 8 ビット エンコードが使われます。つまり、ASCII のファイル パス コンポーネント (ファイル名やフォルダー名など) では、ASCII 文字のサイズが 1 バイトであるため、最大 255 文字まで使用できます。 詳細については、 パスの長さに対する文字バイトの影響を参照してください。

Azure NetApp Files での SMB パスの長さの考慮事項

Azure NetApp Files の SMB パスの長さは、文字のバイト サイズに関係なく、既定で最大 255 文字です。 Windows サーバーとクライアントは、最大 260 バイトのパス長をサポートしますが、<NUL>値やドメイン情報などの Windows パスにメタデータが追加されるため、実際のファイル パスの長さは短くなります。

Windows でパスの制限を超えると、次のダイアログ ボックスが表示されます。

NFS とは異なり、文字の大きなバイト サイズはストレージ システムによって別の領域に格納され、すべての文字はサイズが 1 バイトであるかのように扱われます。 ただし、パスの長さは、パス全体に対して既定で 255 文字に設定されています。つまり、パスの各セグメントの長さも考慮されます。 そのため、SMB 共有のエントリ ポイントは、ファイルまたはフォルダーパス名に使用できる合計文字に影響を与える可能性があります。 たとえば、SMB サーバーの UNC パス名が \\SMB-SHARE\場合、UNC 名はパスの長さ (\を含む) に 12 文字の Unicode 文字を追加します。 特定のファイルへのパスが \\SMB-SHARE\apps\archive\場合、最大 255 文字のうち 25 文字の Unicode 文字になります。 SMB 共有がドライブ文字 (たとえば、 Z:/) にマップされている場合は、255 文字のうち 3 文字のみが使用されます。 つまり、ファイルまたはフォルダーの最大名前の長さは、上記の各シナリオで異なる場合があります。

• \\SMB-SHARE\ (12 文字) は、長さが 243 文字のフォルダーまたはファイル名を許可します
• \\SMB-SHARE\apps\archive\ (25 文字) は、長さが 230 文字のフォルダー名またはファイル名を許可します
• Z:\ (3 文字、 \\SMB-SHARE\apps\archive\にマップ)は、長さが 252 文字のフォルダーまたはファイル名を許可します

SMB 共有の既定の最大パス長は 255 文字 (Windows の制限) ですが、Azure NetApp Files では、最新の Windows サーバーでサポートされている SMB 共有の最大許容パス長 ( 最大 32,767 バイト) もサポートされます。 ただし、Windows クライアントのバージョンによっては、260 バイトより長いパスをサポートできないアプリケーションもあります。 個々のパス コンポーネント (ファイル名やフォルダー名などのスラッシュ間の値) では、最大 255 文字がサポートされます。

ファイル名またはフォルダー名が許可されている最大文字数を超えると、次のエラーが表示されます。

# mkdir 256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

mkdir: cannot create directory ‘256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa’: File name too long 

# mkdir 255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

# ls | grep 255 
255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

Windows での SMB パスの制限の拡張

「パスの最大長の制限」で説明されているように、Windows 10 または Windows Server 2016 バージョン 1607 以降を使っている場合は、レジストリ値を変更して、SMB パスの長さを拡張できます。 この値を変更すると、パスの長さを最大 32,767 バイトまで拡張できます (メタデータを引いた値)。

この機能を有効にしたら、SMB 共有にアクセスするには、長くなったパス長に対応するため、パスで \\?\ を使う必要があります。 この方法は UNC パスをサポートしていないため、SMB 共有をドライブ文字にマップする必要があります。

代わりに \\?\Z: を使ってアクセスでき、より長いファイル パスがサポートされます。

SMB パスの最大長を増やすことができない場合の回避策

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 コマンドを使って照会できます。

文字サイズの識別

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 バイト)。

特殊文字に関する考慮事項

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 での特殊文字の処理について詳しくは、「特殊文字セットでのプロトコルの動作」をご覧ください。

デュアル プロトコル ボリュームに関する考慮事項

デュアル プロトコル アクセスに 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 に短縮されます。

Next steps

• ボリューム言語について理解する