Nommer et référencer des partages, des répertoires, des fichiers et des métadonnées

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 à plusieurs fichiers ou répertoires. Un répertoire contient des propriétés et zéro à plusieurs fichiers ou répertoires. Un objet fichier est toute entité unique composée de données binaires, de propriétés et de métadonnées.

Noms de ressource

L’URI pour 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 dans un partage ou un répertoire donné doit également avoir un nom unique au sein de ce partage ou de ce répertoire.

Si vous essayez de créer un partage, un répertoire ou un fichier avec un nom non conforme aux règles d'affectation des noms, la demande échoue avec le code d'état 400 (Requête incorrecte).

Noms de partage

Les règles pour les noms de partage du service de fichiers sont plus restrictives que ce qui est prescrit par le protocole SMB pour les noms des partages SMB. Les services d'objets blob et de fichiers peuvent ainsi partager des conventions d'affectation des noms similaires pour les conteneurs et pour les partages. Les restrictions d'affectation des 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 ne peuvent contenir que des lettres, des chiffres et le trait d’union/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.
• Un nom de partage doit comprendre entre 3 et 63 caractères.

Le tableau suivant compare les restrictions de nommage pour Azure Files et stockage Blob Azure :

Noms de répertoires et de fichiers

Azure Files applique les règles de nommage suivantes pour les noms de répertoires et de fichiers :

• Les noms des répertoires et des fichiers conservent la casse mais ne respectent pas la casse.
• Les composants des noms de répertoires et de fichiers doivent comprendre au plus 255 caractères.
• Les noms de répertoires ne peuvent pas se terminer par le caractère de barre oblique (/). Si renseignée, elle sera automatiquement supprimée.
• Les noms de fichier ne peuvent pas se terminer par le caractère de barre oblique (/).
• Les caractères d’URL réservées doivent être correctement placés dans une séquence d’échappement.
• Les caractères suivants ne sont pas autorisés : " \ / : | < > * ?
• Les caractères de chemin d’URL illégal ne sont pas autorisés. Les points de code tels que \uE000, bien qu’ils soient valides dans les noms de fichiers NTFS, ne sont pas des caractères Unicode valides. En outre, certains caractères ASCII ou Unicode, comme les caractères de contrôle (0x00 à 0x1F), ne sont pas non plus 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$, caractère point (.) et deux points (..).
• À compter de la version 2021-12-02, les noms de répertoires 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 des protocoles SMB et REST. Les opérations Répertoire de liste et Fichiers et Handles de liste nécessitent une gestion spéciale pour ces caractères, comme indiqué dans leur documentation respective.

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

• Par exemple, si un fichier nommé file1... est en cours de création, les points à la fin seront ignorés et un fichier nommé file1 sera créé. Il en est de même pour les 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 est créé à l’adresse \Dir1\Dir2\File1.
• Toutefois, à compter 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, le doit être inclus dans l’en-tête de la x-ms-allow-trailing-dot demande et défini sur true. Il en est de même pour la création de noms de répertoires.
• Dans le cas d’une 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, case activée les options d’en-tête disponibles pour chaque API REST individuelle.

Le tableau suivant compare les restrictions de nommage pour Azure Files et stockage Blob Azure :

Noms de chemins d’accès

Un nom de chemin d’accès est composé d’un ou plusieurs composants de nom de chemin d’accès (nom de répertoire ou 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 de nom de dernier chemin d’accès désignent les répertoires. Le dernier composant du nom du chemin d'accès indique un répertoire ou un fichier. Les règles d'affectation des noms suivantes s'appliquent :

• Un nom de chemin ne peut pas contenir plus de 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 des métadonnées

Les métadonnées d'une ressource de partage ou 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 de nommage des identificateurs C#.

Notez que les noms de métadonnées conservent la casse avec laquelle ils ont été créés, mais ne la respecte plus quand ils sont définis ou lus. Si deux en-têtes de métadonnées ou plus de même nom sont envoyés pour une ressource, le service de fichiers Azure renvoie le code d'état 400 (Requête incorrecte).

Syntaxe de l’URI de ressource

À chaque ressource correspond un URI de base, qui fait référence à la ressource elle-même. Pour le compte de stockage, l'URI de base inclut le nom du compte seulement :

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

Pour un partage, l'URI de base inclut le nom du compte et celui 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