Comprendre les longueurs de chemin dans Azure NetApp Files

La longueur du fichier et du chemin fait référence au nombre de caractères Unicode autorisés dans un chemin d’accès de fichier, y compris les répertoires. Dans Azure NetApp Files, les protocoles NFS et SMB se comportent un peu différemment dans la façon dont ils traitent les caractères dans les noms de fichiers et de dossiers.

• Dans NFS, la taille en octets des caractères constitue un facteur important en matière de longueur maximale d’un chemin d’accès.
• Dans SMB, la taille d’octet de caractère est moins importante, mais les longueurs de chemin peuvent être affectées par la façon dont le client est configuré et la façon dont le partage SMB est connecté.

Le tableau suivant présente les longueurs de composant et de chemin prises en charge dans les volumes Azure NetApp Files :

Considérations relatives à la longueur du chemin NFS dans Azure NetApp Files

Dans les volumes NFS Azure NetApp Files, la taille en octets des caractères influe sur les longueurs de chemin individuelles. Par exemple, NFS autorise les composants de chemin d’accès d’une taille maximale de 255 octets. Le format d’encodage de fichier ASCII (American Standard Code for Information Interchange) utilise un encodage sur 8 bits, ce qui signifie que les composants du chemin d’accès au fichier (tels que le nom d’un fichier ou d’un dossier) en ASCII peuvent comporter jusqu’à 255 caractères, puisque les caractères ASCII ont une taille égale à 1 octet. Pour découvrir plus d’informations, consultez Impact de l’octet de caractère sur les longueurs de chemin.

Considérations relatives à la longueur du chemin SMB dans Azure NetApp Files

Les longueurs de chemin SMB dans Azure NetApp Files sont par défaut de 255 caractères maximum, quelle que soit la taille d’octet des caractères. Les serveurs Windows et les clients prennent en charge les longueurs de chemin de fichier jusqu’à 260 octets. Cependant, les longueurs réelles des chemins de fichier sont plus courtes en raison de métadonnées ajoutées aux chemins Windows, telles que la valeur <NUL> et les informations de domaine .

Lorsqu’une limite de chemin est dépassée dans Windows, une boîte de dialogue s’affiche :

Contrairement à NFS, les tailles d’octets supérieures pour les caractères sont stockées dans une zone distincte par le système de stockage et tous les caractères sont traités comme s’ils sont de taille de 1 octet. Toutefois, la longueur du chemin d'accès par défaut est de 255 caractères pour l'ensemble du chemin, ce qui signifie que chaque segment du chemin compte dans la longueur totale. En raison de cela, le point d’entrée du partage SMB peut affecter le nombre total de caractères disponibles pour un nom de chemin d’accès de fichier ou de dossier. Par exemple, si le nom du chemin UNC d’un serveur SMB est \\SMB-SHARE\, le nom UNC ajoute 12 caractères Unicode à la longueur du chemin d’accès (y compris \). Si le chemin d’accès à un fichier spécifique est \\SMB-SHARE\apps\archive\, il s’agit de 25 caractères Unicode sur le maximum de 255. Si le partage SMB est mappé à une lettre de lecteur, par exemple Z:/, seuls 3 des 255 caractères sont utilisés. Cela signifie qu’une longueur de nom maximale d’un fichier ou d’un dossier peut être différente dans chacun des scénarios ci-dessus.

• \\SMB-SHARE\ (12 caractères) autoriserait un dossier ou un nom de fichier de 243 caractères de longueur
• \\SMB-SHARE\apps\archive\ (25 caractères) autoriserait un dossier ou un nom de fichier de 230 caractères de longueur
• Z:\ (trois caractères ; mappés à \\SMB-SHARE\apps\archive\) autoriserait un dossier ou un nom de fichier de 252 caractères de longueur

Alors que 255 caractères sont la longueur maximale du chemin d’accès par défaut pour les partages SMB (limite Windows), Azure NetApp Files prend également en charge les mêmes longueurs de chemin autorisées pour les partages SMB que les serveurs Windows modernes prennent en charge : jusqu’à 32 767 octets. Toutefois, selon la version du client Windows, certaines applications ne peuvent pas prendre en charge les chemins de plus de 260 octets. Les composants de chemin d’accès individuels (les valeurs entre les barres obliques, telles que les noms de fichiers ou de dossiers) prennent en charge jusqu’à 255 caractères.

Si un nom de fichier ou de dossier dépasse le nombre maximal de caractères autorisés, l’erreur suivante s’affiche :

# mkdir 256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

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

# mkdir 255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

# ls | grep 255 
255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

Extension des limites de chemin SMB dans Windows

Les longueurs de chemin SMB peuvent être étendues lors de l’utilisation de Windows 10/Windows Server 2016 version 1607 ou ultérieure en modifiant une valeur de Registre comme indiqué dans Limitation de la longueur maximale du chemin. Lorsque cette valeur est modifiée, les longueurs de chemin peuvent s’étendre jusqu’à 32 767 octets (moins les valeurs de métadonnées).

Une fois cette fonctionnalité activée, vous devez accéder au partage SMB à l’aide de \\?\ dans le chemin pour autoriser des longueurs de chemin plus longues. Cette méthode ne prend pas en charge les chemins UNC. Par conséquent, le partage SMB doit être mappé à une lettre de lecteur.

L’utilisation de \\?\Z: à la place autorise l’accès et prend en charge des chemins de fichiers plus longs.

Solution de contournement si la longueur maximale du chemin SMB ne peut pas être augmentée

Si la longueur maximale du chemin ne peut pas être activée dans l’environnement Windows ou si les versions du client Windows sont trop basses, il existe une solution de contournement. Vous pouvez monter le partage SMB plus en profondeur dans la structure de répertoires pour réduire la longueur du chemin interrogé.

Par exemple, au lieu de mapper \\NAS-SHARE\AzureNetAppFiles à Z:, mappez \\NAS-SHARE\AzureNetAppFiles\folder1\folder2\folder3\folder4 à Z:.

Limites de chemin NFS

Les limites de chemin NFS avec les volumes Azure NetApp Files ont la même limite de 255 octets pour les composants de chemin individuels. Toutefois, chaque composant est évalué un par un et peut traiter jusqu’à 4 096 octets par demande avec une longueur de chemin totale presque illimitée. Par exemple, si chaque composant de chemin est de 255 octets, un client NFS peut évaluer jusqu’à 15 composants par demande (y compris les caractères /). Par conséquent, une demande cd vers un chemin au-delà de la limite de 4 096 octets génère un message d’erreur « Nom de fichier trop long ».

Dans la plupart des cas, les caractères Unicode sont de 1 octet ou moins, de sorte que la limite de 4 096 octets correspond à 4 096 caractères. Si un caractère est de taille supérieure à 1 octet, la longueur du chemin est inférieure à 4 096 caractères. Les caractères dont la taille est supérieure à 1 octet comptent plus par rapport au nombre total de caractères que ceux avec une taille de 1 octet.

La longueur maximale du chemin peut être interrogée à l’aide de la commande getconf PATH_MAX /NFSmountpoint.

Distinction des tailles de caractères

L’utilitaire Linux uniutils peut être utilisé pour rechercher la taille d’octet des caractères Unicode en tapant plusieurs instances de l’instance de caractère et en affichant le champ octets.

Exemple 1 : La lettre A majuscule latine est incrémentée de 1 octet chaque fois qu’elle est utilisée (à l’aide d’une seule valeur hexadécimale de 41, qui se trouve dans la plage 0-255 de caractères ASCII).

# 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

Résultat 1 : Le nom AAA utilise 3 octets sur 255.

Exemple 2 : Le caractère japonais 字 incrémente 3 octets par instance. Cela peut également être calculé par les 3 valeurs de code hexadécimales distinctes (E5, AD, 97) sous le champ encodé en tant que. Chaque valeur hexadécimale représente 1 octet :

# 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

Résultat 2 : Un fichier nommé 字字字 utilise 9 octets sur 255.

Exemple 3 : La lettre Ä avec tréma utilise 2 octets par instance (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

Résultat 3 : Un fichier nommé ÄÄÄ utilise 6 octets sur 255.

Exemple 4 : Un caractère spécial, tel que l’emoji 😃, se situe dans une plage non définie qui dépasse les 0 à 3 octets utilisés pour les caractères Unicode. Par conséquent, il utilise une paire de substitution pour son encodage de caractères. Dans ce cas, chaque instance du caractère utilise 4 octets.

# 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 

Résultat 4 : Un fichier nommé 😃😃😃 utilise 12 octets sur 255.

La plupart des emojis se situent dans la plage de 4 octets, mais peuvent atteindre 7 octets. Parmi plus d’un millier d’emojis standard, environ 180 figurent dans le plan multilingue de base (BMP), ce qui signifie qu’ils peuvent être affichés comme texte ou emoji dans Azure NetApp Files, en fonction de la prise en charge du type de langue par le client.

Pour plus d’informations sur le plan BMP et d’autres plans Unicode, consultez Comprendre les langages de volume dans Azure NetApp Files.

Impact de l’octet de caractère sur les longueurs de chemin

Bien qu’une longueur de chemin soit considérée comme le nombre de caractères d’un nom de fichier ou de dossier, il s’agit en fait de la taille des octets pris en charge dans le chemin. Étant donné que chaque caractère ajoute une taille d’octet à un nom, différents jeux de caractères dans différentes langues prennent en charge différentes longueurs de nom de fichier.

Examinez les scénarios suivants :

• Un fichier ou un dossier répète le caractère d’alphabet latin A pour son nom de fichier. (par exemple, AAAAAAAA)

  Comme A utilise 1 octet et que 255 octets est la limite de taille du composant de chemin, 255 instances de A sont autorisées dans un nom de fichier.

• Un fichier ou dossier répète le caractère japonais 字 dans son nom.

  Étant donné que 字 a une taille de 3 octets, la limite de longueur du nom de fichier est de 85 instances de 字 (3 octets * 85 = 255 octets) ou un total de 85 caractères.

• Un fichier ou dossier répète l’emoji de visage très souriant (😃) dans son nom.

Un emoji de visage très souriant (😃) utilise 4 octets, ce qui signifie qu’un nom de fichier avec uniquement cet emoji permettrait un total de 64 caractères (255 octets/4 octets).

• Un fichier ou un dossier utilise une combinaison de caractères différents (autrement dit, Name字😃).

Lorsque des caractères différents avec des tailles d’octets différentes sont utilisés dans un nom de fichier ou de dossier, la taille d’octet de chaque caractère est prise en compte dans la longueur du fichier ou du dossier. Le nom de fichier ou de dossier Name字😃 utiliserait 1+1+1+1+3+4 octets (11 octets) de la longueur totale de 255 octets.

Concepts d’emojis spéciaux

Des emojis spéciaux, tels qu’un emoji drapeau, existent sous la classification BMP : l’emoji s’affiche sous forme de texte ou d’image en fonction de la prise en charge du client. Lorsqu’un client ne prend pas en charge la désignation d’image, il utilise plutôt des désignations textuelles régionales.

Par exemple, le drapeau États-Unis utilise les caractères « us » (qui ressemblent aux caractères latins U+S, mais sont en fait des caractères spéciaux qui utilisent des encodages différents). Uniname affiche les différences entre les caractères.

# 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

Les caractères désignés pour les emojis drapeaux se traduisent par des images de drapeaux dans les systèmes pris en charge, mais restent en tant que valeurs de texte dans les systèmes non pris en charge. Ces caractères utilisent 4 octets par caractère pour un total de 8 octets lorsqu’un emoji drapeau est utilisé. Par conséquent, un total de 31 emojis drapeaux sont autorisés dans un nom de fichier (255 octets/8 octets).

Considérations relatives aux caractères spéciaux

Les volumes Azure NetApp Files utilisent un type de langage C.UTF-8, qui couvre de nombreux pays / langues et langues, notamment l’allemand, le cyrillique, l’hébreu et la plupart des caractères chinois/japonais/coréens (CJK). Les caractères de texte les plus courants dans Unicode sont de 3 octets ou moins. Les caractères spéciaux, tels que les emojis, les symboles musicaux et les symboles mathématiques, sont souvent supérieurs à 3 octets. Certains utilisent la logique de paire de substitution UTF-16.

Si vous utilisez un caractère qu’Azure NetApp Files ne prend pas en charge, vous pouvez voir un avertissement demandant un autre nom de fichier.

Le nom n’est pas trop long, l’erreur résulte en fait de la taille d’octet de caractère trop grande pour le volume Azure NetApp Files à utiliser sur SMB. Il n’existe aucune solution de contournement dans Azure NetApp Files pour cette limitation. Pour plus d’informations sur la gestion des caractères spéciaux dans Azure NetApp Files, consultez Comportements de protocoles avec des jeux de caractères spéciaux.

Considérations relatives aux volumes à deux protocoles

Lors de l’utilisation d’Azure NetApp Files pour un accès à deux protocoles, la différence de traitement des longueurs de chemin dans les protocoles NFS et SMB peut créer des incompatibilités entre les fichiers et les dossiers. Par exemple, SMB Windows prend en charge jusqu’à 32 767 caractères dans un chemin (à condition que la fonctionnalité de chemin long soit activée sur le client SMB), mais la prise en charge de NFS peut dépasser ce montant. Par conséquent, si une longueur de chemin est créée dans NFS qui dépasse la prise en charge de SMB, les clients ne peuvent pas accéder aux données une fois la longueur maximale du chemin atteinte. Dans ces cas, veillez à prendre en compte les limites de fin inférieures des longueurs de chemin de fichier entre les protocoles lors de la création de noms de fichiers et de dossiers (et la profondeur du chemin de dossier) ou à mapper les partages SMB plus près du chemin de dossier souhaité pour réduire la longueur du chemin.

Au lieu de mapper le partage SMB au niveau supérieur du volume pour accéder au chemin \\share\folder1\folder2\folder3\folder4, envisagez de mapper le partage SMB à l’intégralité du chemin \\share\folder1\folder2\folder3\folder4. Par conséquent, un mappage de lettre de lecteur à Z: atterrit dans le dossier souhaité et réduit la longueur du chemin de Z:\folder1\folder2\folder3\folder4\file à Z:\file.

Next steps

• Comprendre les langages de volume