共有、ディレクトリ、ファイル、メタデータの名前付けと参照

ストレージ アカウントには、0 個以上の Azure ファイル共有を含めることができます。 共有には、プロパティ、メタデータ、および 0 個以上のファイルまたはディレクトリが格納されます。 ディレクトリには、プロパティおよび 0 個以上のファイルまたはディレクトリが格納されます。 ファイルは、バイナリ データ、プロパティ、およびメタデータで構成される単一のエンティティです。

リソース名

共有、ディレクトリ、またはファイルを参照する URI は一意である必要があります。 ストレージ アカウント内では、すべての共有名は一意である必要があります。 共有またはディレクトリ内のすべてのファイルの名前もその共有またはディレクトリ内で一意である必要があります。

共有、ディレクトリ、またはファイルを名前付け規則に違反する名前で作成しようとすると、要求はステータス コード 400 (Bad Request) で失敗します。

共有名

コンテナーと共有に対する同じような名前付け規則を BLOB サービスと File サービスで共通化できるように、File サービスの共有名の規則は SMB プロトコルで規定されている SMB 共有名の規則よりも制約が厳しくなっています。 共有の名前付けの制約は、次のとおりです。

• 共有名は有効な DNS 名にする必要があります。
• 共有名は、文字または数字で始まる必要があり、文字、数字、ハイフン/マイナス (-) 文字のみを含めることができます。
• すべてのハイフン/マイナス (-) 文字の直前に文字または数字を付ける必要があります。連続するハイフンは共有名では使用できません。
• 共有名のすべての文字は、小文字にする必要があります。
• 共有名の長さは 3 ～ 63 文字にする必要があります。

次の表は、Azure Filesと Azure Blob Storage の名前付け制限を比較したものです。

ディレクトリとファイルの名前

Azure Filesでは、ディレクトリ名とファイル名に次の名前付け規則が適用されます。

• ディレクトリ名とファイル名では、大文字と小文字が区別されます。
• ディレクトリとファイルのコンポーネント名は 255 文字以下で指定する必要があります。
• ディレクトリ名をスラッシュ文字 (/) で終えることはできません。 使用した場合、自動的に削除されます。
• ファイル名は、スラッシュ (/) で終わることができません。
• URL の予約文字は適切にエスケープしてください。
• 次の文字は使用できません。 " \ / : | < > * ?
• 無効な URL パス文字は使用できません。 のような \uE000コード ポイントは、NTFS ファイル名で有効ですが、有効な Unicode 文字ではありません。 また、制御文字 (0x00 から 0x1F) などの一部の ASCII 文字または Unicode 文字も使用できません。 HTTP/1.1 の Unicode 文字列を管理する規則については、 RFC 2616、セクション 2.2: 基本規則 および RFC 3987 を参照してください。
• 無効な Unicode 文字 (無効なサロゲート ペアと呼ばれます) はサポートされていません。
• 次のファイル名は使用できません: LPT1、LPT2、LPT3、LPT4、LPT5、LPT6、LPT7、LPT8、LPT9、COM1、COM2、COM3、COM4、COM5、COM6、COM7、COM8、COM9、PRN、AUX、NUL、CON、CLOCK$、ドット文字 (..)、2 つのドット文字 (..)。
• バージョン 2021-12-02 以降では、ディレクトリ名とファイル名は、すべての操作で U+FFFE 文字と U+FFFF 文字をサポートします。 これらの文字は、SMB および REST プロトコルでもサポートされます。 リスト ディレクトリとファイルとリスト ハンドルの操作には、それぞれのドキュメントで説明されているように、これらの文字に対して特別な処理が必要です。

既定では、ディレクトリの末尾にあるドット (.) 文字と、要求 URL 内のファイル名は無視されるか、省略されます。

• たとえば、 という名前 file1... のファイルが作成されている場合、末尾のドットは無視され、 という名前 file1 のファイルが作成されます。 パス内のディレクトリにも同じことが当てはまります。 ファイル作成要求に パス \Dir1\Dir2…\File1 が含まれている場合、ファイルは で \Dir1\Dir2\File1作成されます。
• ただし、バージョン 2022-11-02 以降では、URL 要求で ヘッダー x-ms-allow-trailing-dot を に true 設定することで、既定の動作をオーバーライドできます。
• たとえば、 という名前 file1... のファイルを作成し、末尾のドットを含める場合は、 を x-ms-allow-trailing-dot 要求ヘッダーに含め、 を に設定する true必要があります。 ディレクトリ名の作成にも同じことが当てはまります。
• ファイル コピー要求の場合、ソース ファイル名に末尾のドットを含める場合は、ヘッダーを x-ms-source-allow-trailing-dot に設定する true必要があります。 詳細については、各 REST API で使用可能なヘッダー オプションをチェックします。

次の表は、Azure Filesと Azure Blob Storage の名前付け制限を比較したものです。

パス名

パス名は、スラッシュ (/) 文字で区切られた 1 つ以上のパス名コンポーネント (ディレクトリまたはファイル名) で構成されます。 最後のパス名コンポーネント以外のすべてのパス名コンポーネントは、ディレクトリを表します。 最後のパス名コンポーネントは、ディレクトリまたはファイルを表します。 次の名前付け規則が適用されます。

• パス名の長さは 2,048 文字以下です。 パス内の個々のコンポーネントの長さは最大 255 文字です。
• パス名は、スラッシュ (/) 文字で区切られた 1 つ以上のパス名コンポーネントで構成されます。
• パス内のサブディレクトリの深さは 250 を超えることはできません。
• 同じ名前は、同じ親ディレクトリを共有するファイルとディレクトリには使用できません。 たとえば、名前が付けられた data ファイルとディレクトリは、同じ親パスの下に存在できません。

メタデータ名

共有リソースまたはファイル リソースのメタデータは、リソースに関連付けられた名前と値のペアとして保存されます。 メタデータ名は 、C# 識別子の名前付け規則に従う必要があります。

メタデータ名の作成時に指定された大文字と小文字の違いは維持されますが、設定時または読み取り時には大文字と小文字は区別されません。 リソースに対して同じ名前の複数のメタデータ ヘッダーが送信された場合、Azure File サービスはステータス コード 400 (Bad Request) を返します。

リソース URI の構文

各リソースには、リソースそれ自体を参照する、対応するベース URI があります。 ストレージ アカウントの場合、ベース URI にはアカウントの名前だけが含まれます。

https://myaccount.file.core.windows.net

共有の場合、ベース URI にはアカウントの名前と共有の名前が含まれます。

https://myaccount.file.core.windows.net/myshare

ディレクトリの場合、ベース URI にはアカウントの名前、共有の名前、およびディレクトリのパスが含まれます。

https://myaccount.file.core.windows.net/myshare/myparentdir/mydir

ファイルの場合、ベース URI にはアカウントの名前、共有の名前、およびファイルのパスが含まれます。

https://myaccount.file.core.windows.net/myshare/myfile  
https://myaccount.file.core.windows.net/myshare/mydir/myfile  
https://myaccount.file.core.windows.net/myshare/myparentdir/mydir/myfile  

こちらもご覧ください

• ファイル サービスの概念