Descripción de las longitudes de la ruta de acceso en Azure NetApp Files
La longitud de archivo y de ruta de acceso hace referencia al número de caracteres Unicode en una ruta de acceso de archivo, incluidos los directorios. Este límite es un factor en las longitudes de caracteres individuales, que se determinan por el tamaño del carácter en bytes. Por ejemplo, NFS y SMB permiten componentes de ruta de acceso de 255 bytes. El formato de codificación de archivos de ASCII usa codificación de 8 bits, lo que significa que los componentes de la ruta de acceso de archivo (como un nombre de archivo o carpeta) en ASCII pueden tener hasta 255 caracteres, ya que los caracteres ASCII tienen un tamaño de 1 byte.
En la tabla siguiente se muestran las longitudes de la ruta de acceso y componente admitidas en volúmenes de Azure NetApp Files:
| Componente | NFS | SMB |
|---|---|---|
| Tamaño del componente de la ruta de acceso | 255 bytes | 255 bytes |
| Tamaño de la longitud de ruta de acceso | Ilimitado | Valor predeterminado: 255 bytes Máximo en versiones posteriores de Windows: 32 767 bytes |
| Tamaño máximo de la ruta de acceso para transversal | 4096 bytes | 255 bytes |
Nota:
Los volúmenes de protocolo dual usan el valor máximo más bajo.
Si un nombre de recurso compartido de SMB es \\SMB-SHARE, el nombre del recurso compartido agrega 11 caracteres Unicode a la longitud de ruta de acceso porque cada carácter es de 1 byte. Si la ruta de acceso a un archivo específico es \\SMB-SHARE\apps\archive\file, tiene 29 caracteres Unicode; cada carácter, incluida la barra diagonal, es de 1 byte. En el caso de los montajes NFS, se aplican los mismos conceptos. La ruta de acceso del montaje /AzureNetAppFiles es de 17 caracteres Unicode de 1 byte cada uno.
Azure NetApp Files admite la misma longitud de ruta de acceso para los recursos compartidos de SMB que admiten los servidores de Windows modernos: hasta 32 767 bytes. Sin embargo, dependiendo de la versión del cliente de Windows, algunas aplicaciones no pueden admitir rutas de acceso de más de 260 bytes. Los componentes de ruta de acceso individuales (los valores entre barras diagonales, como nombres de archivo o carpeta) admiten hasta 255 bytes. Por ejemplo, un nombre de archivo con la letra "A" mayúscula (que ocupa 1 byte por carácter) en una ruta de acceso de archivo en Azure NetApp Files no puede superar los 255 caracteres.
# mkdir 256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
mkdir: cannot create directory ‘256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa’: File name too long
# mkdir 255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
# ls | grep 255
255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Distinción de tamaños de caracteres
La utilidad uniutils de Linux se puede usar para buscar el tamaño de bytes de caracteres Unicode; para ello, se escriben varias instancias de la instancia de caracteres y se ve el campo bytes.
Ejemplo 1: La mayúscula A aumenta en 1 byte cada vez que se usa (usando un solo valor hexadecimal de 41, que se encuentra en el intervalo de 0 a 255 caracteres 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
Resultado 1: El nombre AAA usa 3 bytes de 255.
Ejemplo 2: El carácter japonés 字 incrementa 3 bytes cada instancia. Esto también se puede calcular mediante los tres valores de código hexadecimal independientes (E5, AD, 97) en el campo codificado como. Cada valor hexadecimal representa 1 byte:
# 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
Resultado 2: Un archivo denominado 字字字 usa 9 bytes de 255.
Ejemplo 3: La letra Ä con diéresis usa 2 bytes por instancia (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
Resultado 3: Un archivo denominado ÄÄÄÄ usa 6 bytes de 255.
Ejemplo 4: Un carácter especial, como el emoji 😃, entra en un intervalo indefinido que supera los 0-3 bytes usados para caracteres Unicode. Como resultado, usa un par suplente para su codificación de caracteres. En este caso, cada instancia del carácter usa 4 bytes.
# 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
Resultado 4: Un archivo denominado 😃😃😃 usa 12 bytes de 255.
La mayoría de los emojis se encuentran en el intervalo de 4 bytes, pero pueden ir hasta 7 bytes. De los más de mil emojis estándar, aproximadamente 180 están en el plano multilingüe básico (BMP), lo que significa que se pueden mostrar como texto o emoji en Azure NetApp Files, en función de la compatibilidad del cliente con el tipo de idioma.
Para obtener información más detallada sobre BMP y otros planos Unicode, consulte Descripción de los lenguajes de volumen en Azure NetApp Files.
Impacto de bytes de caracteres en las longitudes de ruta de acceso
Aunque se cree que una longitud de ruta de acceso es el número de caracteres de un nombre de archivo o carpeta, en realidad es el tamaño de los bytes que se admiten en la ruta de acceso. Dado que cada carácter agrega un tamaño de byte a un nombre, los distintos conjuntos de caracteres en distintos idiomas admiten diferentes longitudes de nombre de archivo.
Considere los casos siguientes:
Un archivo o carpeta repite el carácter latino "A" para su nombre de archivo (por ejemplo, AAAAAAAAAA).
Dado que "A" usa 1 byte y 255 bytes es el límite de tamaño del componente de ruta de acceso, se permitirían 255 instancias de "A" en un nombre de archivo.
Un archivo o carpeta repite el carácter japonés 字 en su nombre.
Dado que "字" tiene un tamaño de 3 bytes, el límite de longitud del nombre de archivo sería de 85 instancias de 字 (3 bytes * 85 = 255 bytes) o un total de 85 caracteres.
Un archivo o carpeta repite el emoji de cara sonriente (😃) en su nombre.
Un emoji de cara sonriente (😃) usa 4 bytes, lo que significa que un nombre de archivo con solo ese emoji permitiría un total de 64 caracteres (255 bytes/4 bytes).
- Un archivo o carpeta usa una combinación de caracteres diferentes (es decir, Nombre字😃).
Cuando se usan caracteres diferentes con distintos tamaños de bytes en un nombre de archivo o carpeta, el tamaño de bytes de cada carácter tiene en cuenta la longitud del archivo o de la carpeta. Un nombre de archivo o carpeta de Nombre字😃 usaría 1+1+1+1+3+4 bytes (11 bytes) de la longitud total de 255 bytes.
Conceptos de los emoji especiales
Los emojis especiales, como un emoji de marca, se encuentran en la clasificación BMP: el emoji se representa como texto o imagen en función de la compatibilidad con el cliente. Cuando un cliente no admite la designación de imagen, en su lugar usa designaciones basadas en texto regionales.
Por ejemplo, la marca de Estados Unidos usa los caracteres "us" (que se asemejan a los caracteres latinos U+S, pero en realidad son caracteres especiales que utilizan diferentes codificaciones). Uniname muestra las diferencias entre los caracteres.
# 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
Los caracteres designados para los emojis de marca se traducen en imágenes de marca en sistemas compatibles, pero permanecen como valores de texto en sistemas no admitidos. Estos caracteres usan 4 bytes por carácter para un total de 8 bytes cuando se usa un emoji de marca. Por lo tanto, se permite un total de 31 emojis de marca en un nombre de archivo (255 bytes/8 bytes).
Límites de ruta de acceso de SMB
De forma predeterminada, los servidores de Windows y los clientes admiten longitudes de ruta de acceso de hasta 260 bytes, pero las longitudes de ruta de acceso de archivo reales son más cortas debido a los metadatos agregados a las rutas de acceso de Windows, como el valor <NUL> y la información del dominio.
Cuando se supera un límite de ruta de acceso en Windows, aparece un cuadro de diálogo:
Las longitudes de ruta de acceso SMB se pueden extender cuando se usa Windows 10 o Windows Server 2016 versión 1607 o posterior cambiando un valor del Registro como se describe en Limitación de longitud máxima de ruta de acceso. Cuando se cambia este valor, las longitudes de ruta de acceso pueden extenderse hasta 32 767 bytes (menos los valores de metadatos).
Una vez habilitada esta característica, debe acceder a las necesidades del recurso compartido de SMB mediante \\?\ en la ruta de acceso para permitir longitudes de ruta de acceso más largas. Este método no admite rutas de acceso UNC, por lo que el recurso compartido de SMB debe asignarse a una letra de unidad.
El uso de \\?\Z: en su lugar permite el acceso y admite rutas de acceso de archivo más largas.
Nota:
Windows CMD no admite actualmente el uso de \\?\.
Solución alternativa si no se puede aumentar la longitud máxima de la ruta de acceso
Si la longitud máxima de la ruta de acceso no se puede habilitar en el entorno de Windows o las versiones de cliente de Windows son demasiado bajas, hay una solución alternativa. Puede montar el recurso compartido SMB más profundo en la estructura de directorios y reducir la longitud de la ruta de acceso consultada.
Por ejemplo, en lugar de asignar \\NAS-SHARE\AzureNetAppFiles a Z:, asigne \\NAS-SHARE\AzureNetAppFiles\folder1\folder2\folder3\folder4 a Z:.
Límites de ruta de acceso NFS
Los límites de ruta de acceso NFS con volúmenes de Azure NetApp Files tienen el mismo límite de 255 bytes para los componentes de ruta de acceso individuales. Sin embargo, cada componente se evalúa de uno en uno y puede procesar hasta 4096 bytes por solicitud con una longitud total de ruta de acceso casi ilimitada. Por ejemplo, si cada componente de ruta de acceso es de 255 bytes, un cliente NFS puede evaluar hasta 15 componentes por solicitud (incluidos / caracteres). Por lo tanto, una solicitud cd a una ruta de acceso a lo largo del límite de 4096 bytes produce un mensaje de error "Nombre de archivo demasiado largo".
En la mayoría de los casos, los caracteres Unicode son de 1 byte o menos, por lo que el límite de 4096 bytes corresponde a 4096 caracteres. Si un carácter es mayor que 1 byte de tamaño, la longitud de ruta de acceso es inferior a 4096 caracteres. Los caracteres con un tamaño superior a 1 byte cuentan más con respecto al recuento total de caracteres que los caracteres de 1 byte.
La longitud máxima de la ruta de acceso se puede consultar mediante el comando getconf PATH_MAX /NFSmountpoint.
Nota:
El límite se define en el archivo limits.h en el cliente NFS. No debe ajustar estos límites.
Consideraciones sobre el volumen de protocolo dual
Al usar Azure NetApp Files para el acceso de protocolo dual, la diferencia en cómo se controlan las longitudes de ruta de acceso en los protocolos NFS y SMB pueden crear incompatibilidades entre archivos y carpetas. Por ejemplo, SMB de Windows admite hasta 32 767 caracteres en una ruta de acceso (siempre que la característica de ruta de acceso larga esté habilitada en el cliente SMB), pero la compatibilidad con NFS puede superar esa cantidad. Por lo tanto, si se crea una longitud de ruta de acceso en NFS que supera la compatibilidad de SMB, los clientes no pueden acceder a los datos una vez alcanzados los valores máximos de longitud de ruta de acceso. En esos casos, tenga cuidado de tener en cuenta los límites inferiores de las longitudes de ruta de acceso de archivo entre protocolos al crear nombres de archivo y carpeta (y profundidad de ruta de acceso de carpeta) o asignar recursos compartidos de SMB más cerca de la ruta de acceso de carpeta deseada para reducir la longitud de ruta de acceso.
En lugar de asignar el recurso compartido de SMB al nivel superior del volumen para navegar a una ruta de acceso de \\share\folder1\folder2\folder3\folder4, considere la posibilidad de asignar el recurso compartido de SMB a toda la ruta de acceso de \\share\folder1\folder2\folder3\folder4. Como resultado, una asignación de letra de unidad Z: llega a la carpeta deseada y reduce la longitud de ruta de acceso de Z:\folder1\folder2\folder3\folder4\file a Z:\file.
Consideraciones de caracteres especiales
Los volúmenes de Azure NetApp Files usan un tipo de lenguaje de C.UTF-8, que cubre muchos países e idiomas, como alemán, cirílico, hebreo y la mayoría de chinos, japoneses y coreanos (CJK). Los caracteres de texto más comunes de Unicode son 3 bytes o menos. Los caracteres especiales,como emojis, símbolos musicales y símbolos matemáticos, suelen ser mayores de 3 bytes. Algunos usan la lógica de par suplente UTF-16.
Si usa un carácter que Azure NetApp Files no admite, es posible que vea una advertencia que solicita un nombre de archivo diferente.
En lugar de que el nombre sea demasiado largo, el error realmente da como resultado que el tamaño del byte de caracteres sea demasiado grande para que el volumen de Azure NetApp Files se utilice a través de SMB. No hay ninguna solución alternativa en Azure NetApp Files para esta limitación. Para más información sobre el control de caracteres especiales en Azure NetApp Files, consulte Comportamiento del protocolo con juegos de caracteres especiales.