Partager via

Affectation de noms et référencement de partages, de répertoires, de fichiers et de métadonnées

  • Article

Un compte de stockage peut contenir zéro ou plusieurs partages de fichiers Azure. Un partage contient des propriétés, des métadonnées et zéro ou plusieurs fichiers ou répertoires. Un répertoire contient des propriétés et zéro ou plusieurs fichiers ou répertoires. Un fichier est n’importe quelle entité unique composée de données binaires, de propriétés et de métadonnées.

Noms de ressources

L’URI permettant de référencer un partage, un répertoire ou un fichier doit être unique. Dans un compte de stockage donné, chaque partage doit avoir un nom unique. Chaque fichier d’un partage ou d’un répertoire donné doit également avoir un nom unique dans ce partage ou répertoire.

Si vous tentez de créer un partage, un répertoire ou un fichier avec un nom qui enfreint les règles d’affectation de noms, la demande échoue avec le code d’état 400 (demande incorrecte).

Noms de partages

Les règles pour les noms de partage de service de fichiers sont plus restrictives que ce qui est prescrit par le protocole SMB pour les noms de partage SMB, afin que les services d’objets blob et de fichiers puissent partager des conventions d’affectation de noms similaires pour les conteneurs et les partages. Les restrictions d’affectation de noms pour les partages sont les suivantes :

  • Un nom de partage doit être un nom DNS valide.
  • Les noms de partage doivent commencer par une lettre ou un nombre, et peuvent contenir uniquement des lettres, des chiffres et le caractère tiret/moins (-).
  • Chaque trait d’union/moins (-) doit être immédiatement précédé et suivi d’une lettre ou d’un nombre ; les traits d’union consécutifs ne sont pas autorisés dans les noms de partage.
  • Toutes les lettres d’un nom de partage doivent être en minuscules.
  • Les noms de partage doivent être de 3 à 63 caractères.

Le tableau suivant compare les restrictions d’affectation de noms pour Azure Files et le stockage Blob Azure :

nommage et référencement de conteneurs, d’objets blob et de métadonnées restrictions de nom de partage SMB
• Un nom de conteneur doit être un nom DNS valide.
• Les noms de conteneur doivent commencer par une lettre ou un nombre, et ne peuvent contenir que des lettres, des chiffres et le caractère tiret/moins (-).
• Chaque trait d’union/moins (-) doit être immédiatement précédé et suivi d’une lettre ou d’un nombre ; les traits d’union consécutifs ne sont pas autorisés dans les noms de conteneurs.
• Toutes les lettres d’un nom de conteneur doivent être minuscules.
• Les noms de conteneur doivent être de 3 à 63 caractères.		 • Un nom de partage ne doit pas dépasser 80 caractères.
• Les caractères suivants ne sont pas valides dans un nom de partage : \ / [ ] : ¦ < > + = ; , * ? "
• Les caractères de contrôle dans la plage 0x00 via 0x1F, inclus, sont interdits dans un nom de partage.
• Tous les autres caractères Unicode sont légaux.
• Les noms respectent la casse et ne respectent pas la casse.

Noms de répertoires et de fichiers

Azure Files applique les règles d’affectation de noms suivantes pour les noms de répertoire et de fichiers :

  • Les noms de répertoires et de fichiers respectent la casse et ne respectent pas la casse.
  • Les noms des composants de répertoire et de fichier ne doivent pas dépasser 255 caractères.
  • Les noms de répertoires ne peuvent pas se terminer par le caractère de barre oblique (/). S’il est fourni, il sera automatiquement supprimé.
  • Les noms de fichiers ne doivent pas se terminer par le caractère de barre oblique (/).
  • Les caractères d’URL réservés doivent être correctement placés dans l’échappement.
  • Les caractères suivants ne sont pas autorisés : " \ / : | < > * ?
  • Les caractères de chemin d’accès d’URL non valides ne sont pas autorisés. Les points de code comme \uE000, alors qu’ils sont valides dans les noms de fichiers NTFS, ne sont pas des caractères Unicode valides. En outre, certains caractères ASCII ou Unicode, tels que les caractères de contrôle (0x00 à 0x1F), ne sont pas autorisés. Pour connaître les règles régissant les chaînes Unicode dans HTTP/1.1, consultez RFC 2616, section 2.2 : Règles de base et RFC 3987.
  • Les caractères Unicode non valides (appelés paires de substitution non valides) ne sont pas pris en charge.
  • Les noms de fichiers suivants ne sont pas autorisés : LPT1, LPT2, LPT3, LPT4, LPT5, LPT6, LPT7, LPT8, LPT9, COM1, COM2, COM3, COM4, COM5, COM6, COM7, COM8, COM9, PRN, AUX, NUL, CON, CLOCK$, dot character (.) et deux points (..).
  • À compter de la version 2021-12-02, les noms de répertoire et de fichiers prennent en charge les caractères U+FFFE et U+FFFF via toutes les opérations. Ces caractères sont également pris en charge par le biais de protocoles SMB et REST. répertoire de liste et fichiers et handles de liste opérations nécessitent une gestion spéciale pour ces caractères, comme indiqué dans leur documentation respective.

Par défaut, pour les partages de fichiers avec le protocole SMB activé, les caractères point (.) à la fin du répertoire et des noms de fichiers dans les URL de requête sont ignorés ou ignorés.

  • Par exemple, si un fichier nommé file1... est créé, les points à la fin sont ignorés et un fichier nommé file1 est créé. La même chose s’applique aux répertoires dans le chemin d’accès. Si une demande de création de fichier inclut le chemin d’accès \Dir1\Dir2…\File1 le fichier sera créé à \Dir1\Dir2\File1.
  • Toutefois, à partir de la version 2022-11-02, le comportement par défaut peut être remplacé en définissant l’en-tête x-ms-allow-trailing-dot sur true dans la demande d’URL.
  • Par exemple, si vous souhaitez créer un fichier nommé file1... et inclure les points de fin, l'x-ms-allow-trailing-dot doit être inclus dans l’en-tête de la demande et défini sur true. La même chose s’applique à la création de noms d’annuaires.
  • En cas de demande de copie de fichier, si vous souhaitez inclure des points de fin dans le nom du fichier source, l’en-tête x-ms-source-allow-trailing-dot doit être défini sur true. Pour plus d’informations, consultez les options d’en-tête disponibles pour chaque API REST individuelle.

Par défaut, pour les partages de fichiers avec le protocole NFS activé, les caractères point (.) à la fin du répertoire et des noms de fichiers dans les URL de requête ne sont pas ignorés.

Le tableau suivant compare les restrictions d’affectation de noms pour Azure Files et le stockage Blob Azure :

nommage et référencement de conteneurs, d’objets blob et de métadonnées restrictions de nom de protocole SMB
• Un nom d’objet blob doit avoir au moins un caractère long et ne peut pas comporter plus de 1 024 caractères.
• Les noms d’objets blob respectent la casse.
• Les caractères d’URL réservés doivent être correctement placés dans l’échappement.
• Les noms d’objets blob peuvent se terminer par un délimiteur de répertoire virtuel, tel qu’une barre oblique (/)
• Caractères de chemin d’accès d’URL non autorisés : les points de code comme \uE000, tandis qu’ils sont valides dans les noms de fichiers NTFS, ne sont pas des caractères Unicode valides. En outre, certains caractères ASCII ou Unicode, tels que les caractères de contrôle (0x00 à 0x1F), ne sont pas autorisés. Pour connaître les règles régissant les chaînes Unicode dans HTTP/1.1, consultez RFC 2616, section 2.2 : Règles de base et RFC 3987.		 • Un nom de chemin d’accès ne peut pas dépasser 32 760 caractères.
• Chaque composant de nom de chemin d’accès (fichier/répertoire) ne peut pas dépasser 255 caractères de longueur.
• Un nom de chemin d’accès est composé d’un ou plusieurs composants de nom de chemin séparés par le caractère (\) de barre oblique vers l’arrière.
• Le nom du chemin d’accès conserve et ne respecte pas la casse (deux noms qui diffèrent uniquement dans le cas n’est pas autorisé).
• Impossible d’avoir un chemin d’accès de répertoire identique à un chemin d’accès de fichier.
• Les caractères suivants ne sont pas valides dans un nom de composant : \ / : ¦ < > * ? "
• Les caractères de contrôle dans la plage 0x00 via 0x1F, inclus, sont interdits dans un nom de partage.

Noms de chemins d’accès

Un nom de chemin est composé d’un ou plusieurs composants de nom de chemin d’accès (répertoire ou nom de fichier) séparés par le caractère de barre oblique (/). Tous les composants de nom de chemin d’accès autres que le composant nom du dernier chemin d’accès désignent les répertoires. Le dernier composant de nom de chemin d’accès désigne un répertoire ou un fichier. Les règles d’affectation de noms suivantes s’appliquent :

  • Un nom de chemin d’accès ne peut pas dépasser 2 048 caractères. Les composants individuels du chemin d’accès peuvent avoir une longueur maximale de 255 caractères.
  • Un nom de chemin d’accès est composé d’un ou plusieurs composants de nom de chemin séparés par le caractère de barre oblique (/).
  • La profondeur des sous-répertoires dans le chemin ne peut pas dépasser 250.
  • Le même nom ne peut pas être utilisé pour un fichier et un répertoire qui partagent le même répertoire parent. Par exemple, un fichier et un répertoire nommés data ne peuvent pas exister sous le même chemin parent.

Noms de métadonnées

Les métadonnées d’un partage ou d’une ressource de fichier sont stockées en tant que paires nom-valeur associées à la ressource. Les noms de métadonnées doivent respecter les règles d’affectation de noms pour les identificateurs C# .

Les noms de métadonnées conservent le cas avec lequel ils ont été créés, mais ne respectent pas la casse lors de la définition ou de la lecture. Si deux en-têtes de métadonnées ou plus portant le même nom sont envoyés pour une ressource, le service Azure File retourne le code d’état 400 (demande incorrecte).

Syntaxe de l’URI de ressource

Chaque ressource a un URI de base correspondant, qui fait référence à la ressource elle-même. Pour le compte de stockage, l’URI de base inclut uniquement le nom du compte :

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

Pour un partage, l’URI de base inclut le nom du compte et le nom du partage :

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

Pour un répertoire, l’URI de base inclut le nom du compte, le nom du partage et le chemin d’accès du répertoire :

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

Pour un fichier, l’URI de base inclut le nom du compte, le nom du partage et le chemin d’accès du fichier :

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

Voir aussi

  • Concepts du service de fichiers