Entender os comprimentos do caminho no Azure NetApp Files
O comprimento do arquivo e do caminho refere-se ao número de caracteres Unicode em um caminho de arquivo, incluindo diretórios. Esse limite é um fator dos tamanhos de caractere individuais, que são determinados pelo tamanho do caractere em bytes. Por exemplo, NFS e SMB permitem componentes de caminho de 255 bytes. O formato de codificação de arquivo do ASCII (American Standard Code for Information Interchange) usa codificação de 8 bits, o que significa que os componentes do caminho do arquivo (como um nome de arquivo ou pasta) no ASCII podem ter até 255 caracteres, já que os caracteres ASCII têm 1 byte de tamanho.
A seguinte tabela mostra os comprimentos de componente e caminho compatíveis com volumes do Azure NetApp Files:
| Componente | NFS | SMB |
|---|---|---|
| Tamanho do componente do caminho | 255 bytes | 255 bytes |
| Tamanho do comprimento do caminho | Ilimitado | Padrão: 255 bytes Máximo em versões posteriores do Windows: 32.767 bytes |
| Tamanho máximo do caminho para transversal | 4.096 bytes | 255 bytes |
Observação
Os volumes de protocolo duplo usam o menor valor máximo.
Se um nome de compartilhamento SMB for \\SMB-SHARE, o nome do compartilhamento adicionará 11 caracteres Unicode ao comprimento do caminho porque cada caractere é 1 byte. Se o caminho para um arquivo específico for \\SMB-SHARE\apps\archive\file, serão 29 caracteres Unicode; cada caractere, incluindo as barras, tem 1 byte. Para montagens NFS, os mesmos conceitos se aplicam. O caminho de montagem /AzureNetAppFiles tem 17 caracteres Unicode de 1 byte cada.
O Azure NetApp Files dá suporte ao mesmo comprimento de caminho para compartilhamentos SMB que o suportado pelos servidores Windows modernos: até 32.767 bytes. No entanto, dependendo da versão do cliente Windows, alguns aplicativos não podem dar suporte a caminhos com mais de 260 bytes. Componentes de caminho individuais (os valores entre barras, como nomes de arquivo ou pasta) dão suporte a até 255 bytes. Por exemplo, um nome de arquivo usando a letra “A” latina maiúscula (que ocupa 1 byte por caractere) em um caminho de arquivo no Azure NetApp Files não pode exceder 255 caracteres.
# mkdir 256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
mkdir: cannot create directory ‘256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa’: File name too long
# mkdir 255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
# ls | grep 255
255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
Diferenciação entre tamanhos de caractere
O utilitário Linux uniutils pode ser usado para localizar o tamanho de bytes de caracteres Unicode digitando várias instâncias da instância de caractere e exibindo o campo bytes.
Exemplo 1: o A latino maiúsculo incrementa 1 byte cada vez que é usado (usando apenas um valor hex de 41, que está no 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: o nome AAA usa 3 bytes de 255.
Exemplo 2: o caractere japonês 字 incrementa 3 bytes a cada instância. Isso também pode ser calculado pelos três valores de código hexadecimais separados (E5, AD, 97) no 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: um arquivo chamado 字字字 usa 9 bytes de 255.
Exemplo 3: a letra Ä com trema usa 2 bytes por instância (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: um arquivo chamado ÄÄÄ usa 6 bytes de 255.
Exemplo 4: Um caractere especial, como o emoji 😃, se enquadra em um intervalo indefinido que excede os 0-3 bytes usados para caracteres Unicode. Como resultado, ele usa um par alternativo para a própria codificação de caracteres. Nesse caso, cada instância do caractere 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: um arquivo chamado 😃😃😃 usa 12 bytes de 255.
A maioria dos emojis se enquadra no intervalo de 4 bytes, mas pode ir até 7 bytes. Dos mais de mil emojis padrão, aproximadamente 180 estão no BMP (plano multilíngue básico), o que significa que eles podem ser exibidos como texto ou emoji no Azure NetApp Files, dependendo se cliente dá suporte para o tipo de linguagem.
Para obter informações mais detalhadas sobre o BMP e outros planos Unicode, consulte Noções básicas sobre linguagens de volume no Azure NetApp Files.
Impacto de bytes de caractere nos comprimentos do caminho
Embora um comprimento de caminho seja considerado o número de caracteres em um nome de arquivo ou pasta, na verdade é o tamanho dos bytes com suporte no caminho. Como cada caractere adiciona um tamanho de byte a um nome, conjuntos de caracteres diferentes em linguagens diferentes dão suporte a diferentes comprimentos de nome de arquivo.
Considere os seguintes cenário:
Um arquivo ou pasta repete o caractere “A” do alfabeto latino para seu nome de arquivo. (por exemplo, AAAAAAAA)
Como “A” usa 1 byte e 255 bytes é o limite de tamanho do componente de caminho, então 255 instâncias de “A” seriam permitidas em um nome de arquivo.
Um arquivo ou pasta repete o caractere japonês 字 em seu nome.
Como “字” tem um tamanho de 3 bytes, o limite de comprimento do nome do arquivo seria de 85 instâncias de 字 (3 bytes * 85 = 255 bytes) ou um total de 85 caracteres.
Um arquivo ou pasta repete o emoji de rosto sorridente (😃) em seu nome.
Um emoji de rosto sorridente (😃) usa 4 bytes, o que significa que um nome de arquivo com apenas esse emoji permitiria um total de 64 caracteres (255 bytes/4 bytes).
- Um arquivo ou pasta usa uma combinação de caracteres diferentes (ou seja, Name字😃).
Quando diferentes caracteres com tamanhos de bytes diferentes são usados em um nome de arquivo ou pasta, cada caractere tem fatores de tamanho de byte no tamanho do arquivo ou da pasta. Um nome de arquivo ou pasta de Name字😃 usaria 1+1+1+1+3+4 bytes (11 bytes) do tamanho total de 255 bytes.
Conceitos especiais de emoji
Emojis especiais, como um emoji de sinalizador, existem sob a classificação BMP: o emoji é renderizado como texto ou imagem, dependendo do suporte do cliente. Quando um cliente não dá suporte à designação de imagem, ele usa designações regionais baseadas em texto.
Por exemplo, a bandeira dos Estados Unidos usa os caracteres "us" (que se assemelham aos caracteres latinos U+S, mas na verdade são caracteres especiais que usam codificações diferentes). O Uniname mostra as diferenças entre os 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
Os caracteres designados para os emojis de bandeira se traduzem em imagens de bandeira em sistemas com suporte, mas permanecem como valores de texto em sistemas sem suporte. Esses caracteres usam 4 bytes por caractere para um total de 8 bytes quando um emoji de bandeira é usado. Dessa forma, um total de 31 emojis de bandeira são permitidos em um nome de arquivo (255 bytes/8 bytes).
Limites de caminho SMB
Por padrão, clientes e servidores Windows dão suporte a tamanhos de caminho de até 260 bytes, mas os comprimentos reais do caminho do arquivo são mais curtos devido a metadados adicionados a caminhos do Windows, como o valor <NUL> e as informações de domínio.
Quando um limite de caminho é excedido no Windows, uma caixa de diálogo é exibida:
Os comprimentos do caminho SMB podem ser estendidos ao usar o Windows 10/Windows Server 2016 versão 1607 ou posterior alterando um valor do Registro, conforme abordado em Limitação máxima de comprimento do caminho. Quando esse valor é alterado, os comprimentos do caminho podem se estender até 32.767 bytes (menos valores de metadados).
Depois que esse recurso estiver habilitado, você deverá acessar as necessidades de compartilhamento SMB usando \\?\ no caminho para permitir comprimentos de caminho mais longos. Esse método não dá suporte a caminhos UNC, portanto, o compartilhamento SMB precisa ser mapeado para uma letra da unidade.
Em vez disso, usar \\?\Z: permite acesso e dá suporte a caminhos de arquivo mais longos.
Observação
Atualmente, o CMD do Windows não dá suporte ao uso de \\?\.
Solução alternativa se o comprimento máximo do caminho não puder ser aumentado
Se o comprimento máximo do caminho não puder ser habilitado no ambiente do Windows ou as versões do cliente Windows forem muito baixas, haverá uma solução alternativa. Você pode montar o compartilhamento do SMB mais profundamente na estrutura do diretório e reduzir o comprimento do caminho consultado.
Por exemplo, em vez de mapear \\NAS-SHARE\AzureNetAppFiles para Z:, mapeie \\NAS-SHARE\AzureNetAppFiles\folder1\folder2\folder3\folder4 para Z:.
Limites de caminho NFS
Os limites de caminho do NFS com volumes do Azure NetApp Files têm o mesmo limite de 255 bytes para componentes de caminho individuais. Cada componente, no entanto, é avaliado por vez e pode processar até 4.096 bytes por solicitação com um comprimento de caminho total quase ilimitado. Por exemplo, se cada componente de caminho for de 255 bytes, um cliente NFS poderá avaliar até 15 componentes por solicitação (incluindo caracteres /). Dessa forma, uma solicitação cd para um caminho acima do limite de 4.096 bytes gera uma mensagem de erro "Nome do arquivo longo demais".
Na maioria dos casos, os caracteres Unicode têm 1 byte ou menos, portanto, o limite de 4.096 bytes corresponde a 4.096 caracteres. Se um caractere tiver tamanho maior que 1 byte, o comprimento do caminho será menor que 4.096 caracteres. Caracteres com um tamanho maior que 1 byte contam mais em relação à contagem total de caracteres do que caracteres de 1 byte.
É possível consultar esses valores usando o comando getconf PATH_MAX /NFSmountpoint.
Observação
O limite é definido no arquivo limits.h no cliente NFS. Você não deve ajustar esses limites.
Considerações sobre volume de protocolo duplo
Ao usar o Azure NetApp Files para acesso de protocolo duplo, a diferença em como os comprimentos de caminho são tratados em protocolos NFS e SMB pode criar incompatibilidades entre arquivos e pastas. Por exemplo, o SMB do Windows dá suporte a até 32.767 caracteres em um caminho (desde que o recurso de caminho longo esteja habilitado no cliente SMB), mas o suporte ao NFS pode exceder esse valor. Dessa forma, se um comprimento de caminho for criado no NFS que exceder o suporte do SMB, os clientes não poderão acessar os dados depois que os valores máximos de comprimento do caminho forem atingidos. Nesses casos, tome cuidado para considerar os limites inferiores de comprimentos de caminho de arquivo entre protocolos ao criar nomes de arquivo e pasta (e profundidade do caminho da pasta) ou mapear compartilhamentos SMB mais próximos do caminho de pasta desejado para reduzir o comprimento do caminho.
Em vez de mapear o compartilhamento SMB para o nível superior do volume para navegar até um caminho de \\share\folder1\folder2\folder3\folder4, considere mapear o compartilhamento SMB para todo o caminho de \\share\folder1\folder2\folder3\folder4. Como resultado, um mapeamento de letra da unidade para Z: chega à pasta desejada e reduz o comprimento do caminho de Z:\folder1\folder2\folder3\folder4\file para Z:\file.
Considerações sobre caracteres especiais
Os volumes do Azure NetApp Files usam um tipo de linguagem C.UTF-8, que abrange muitos países/regiões e idiomas, incluindo alemão, cirílico, hebraico e a maior parte dos caracteres CJK (chinês/japonês/coreano). Os caracteres de texto mais comuns no Unicode têm 3 bytes ou menos. Caracteres especiais (como emojis, símbolos musicais e símbolos matemáticos) geralmente são maiores que 3 bytes. Alguns usam lógica de par alternativo UTF-16.
Se você usar um caractere não compatível com o Azure NetApp Files, poderá ver um aviso solicitando um nome de arquivo diferente.
Em vez de o nome ser muito longo, o erro resulta, na verdade, do tamanho do byte do caractere ser muito grande para o volume do Azure NetApp Files usar em SMB. Não há nenhuma solução alternativa no Azure NetApp Files para essa limitação. Para obter mais informações sobre o tratamento especial de caracteres no Azure NetApp Files, consulte Comportamento de protocolo com conjuntos de caracteres especiais.