Compreender os comprimentos de caminho nos Arquivos NetApp do Azure

O comprimento do arquivo e do caminho refere-se ao número de caracteres Unicode permitidos em um caminho de arquivo, incluindo diretórios. Nos Arquivos NetApp do Azure, os protocolos NFS e SMB se comportam de forma um pouco diferente na forma como tratam os caracteres em nomes de arquivos e pastas.

• No NFS, o tamanho do byte de caractere é um fator importante em quanto tempo um caminho pode ser.
• No SMB, o tamanho do byte de caractere é menos importante, mas os comprimentos do caminho podem ser afetados pela forma como o cliente é configurado e como o compartilhamento SMB está conectado.

A tabela a seguir mostra os comprimentos de componente e caminho suportados nos volumes do Azure NetApp Files:

Considerações sobre o comprimento do caminho NFS nos Arquivos NetApp do Azure

Nos volumes NFS do Azure NetApp Files, o tamanho do byte de caractere é um fator nos comprimentos de caminho individuais. Por exemplo, o NFS permite componentes de caminho de um tamanho máximo de 255 bytes. O formato de codificação de arquivo do American Standard Code for Information Interchange (ASCII) usa codificação de 8 bits, o que significa que os componentes de caminho de arquivo (como um nome de arquivo ou pasta) em ASCII podem ter até 255 caracteres, já que os caracteres ASCII têm 1 byte de tamanho. Para obter mais informações, consulte Impacto de byte de caractere em comprimentos de caminho.

Considerações sobre o comprimento do caminho SMB nos Arquivos NetApp do Azure

Os comprimentos de caminho SMB nos Arquivos NetApp do Azure são padrão para um máximo de 255 caracteres, independentemente do tamanho do byte dos caracteres. Os servidores e clientes Windows suportam comprimentos de caminho de até 260 bytes, mas os comprimentos reais do caminho do arquivo são menores devido aos metadados adicionados aos caminhos do Windows, como o valor e as informações de <NUL> domínio.

Quando um limite de caminho é excedido no Windows, uma caixa de diálogo aparece:

Ao contrário do NFS, tamanhos de bytes maiores para caracteres são armazenados em uma área separada pelo sistema de armazenamento e todos os caracteres são tratados como se tivessem 1 byte de tamanho. No entanto, o comprimento do caminho assume como padrão 255 caracteres para todo o caminho, o que significa que cada segmento do caminho é considerado. Por isso, o ponto de entrada do compartilhamento SMB pode afetar o total de caracteres disponíveis para um nome de caminho de arquivo ou pasta. Por exemplo, se o nome do caminho UNC de um servidor SMB for \\SMB-SHARE\, o nome UNC adicionará 12 caracteres Unicode ao comprimento do caminho (incluindo \). Se o caminho para um arquivo específico for \\SMB-SHARE\apps\archive\, são 25 caracteres Unicode do máximo de 255. Se o compartilhamento SMB for mapeado para uma letra de unidade (digamos, Z:/), apenas 3 dos 255 caracteres serão usados. Isso significa que o comprimento máximo do nome de um arquivo ou pasta pode ser diferente em cada um dos cenários acima.

• \\SMB-SHARE\ (12 caracteres) permitiria um nome de pasta ou arquivo com 243 caracteres de comprimento
• \\SMB-SHARE\apps\archive\ (25 caracteres) permitiria um nome de pasta ou arquivo com 230 caracteres de comprimento
• Z:\ (três caracteres; mapeados para \\SMB-SHARE\apps\archive\) permitiria um nome de pasta ou arquivo com 252 caracteres

Embora 255 caracteres seja o comprimento máximo de caminho padrão para compartilhamentos SMB (limite do Windows), os Arquivos NetApp do Azure também oferecem suporte aos mesmos comprimentos de caminho permitidos maiores para compartilhamentos SMB que os servidores Windows modernos suportam: até 32.767 bytes. No entanto, dependendo da versão do cliente Windows, alguns aplicativos não podem suportar caminhos com mais de 260 bytes. Os componentes de caminho individuais (os valores entre barras, como nomes de arquivos ou pastas) suportam até 255 caracteres.

Se um nome de arquivo ou pasta exceder o número máximo de caracteres permitidos, o seguinte erro será exibido:

# mkdir 256charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

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

# mkdir 255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

# ls | grep 255 
255charsaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa 

Estendendo os limites de caminho SMB no Windows

Os comprimentos de 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 de comprimento máximo de caminho. Quando esse valor é alterado, os comprimentos de caminho podem se estender até 32.767 bytes (menos valores de metadados).

Depois que esse recurso estiver habilitado, você deve acessar as necessidades de compartilhamento SMB usando \\?\ no caminho para permitir comprimentos de caminho mais longos. Este método não oferece suporte a caminhos UNC, por isso, o compartilhamento SMB precisa ser mapeado para uma letra de disco.

Em vez disso, o uso \\?\Z: permite o acesso e suporta caminhos de arquivo mais longos.

Solução alternativa se o comprimento máximo do caminho SMB não puder ser aumentado

Se o comprimento máximo do caminho não puder ser habilitado no ambiente Windows ou se as versões do cliente Windows forem muito baixas, há uma solução alternativa. Você pode montar o compartilhamento SMB mais profundamente na estrutura de diretórios 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 caminhos do NFS

As restrições de caminho NFS com os volumes do Azure NetApp Files têm o mesmo limite de 255 bytes para componentes individuais do caminho. Cada componente, no entanto, é avaliado um de cada vez e pode processar até 4.096 bytes por solicitação com um comprimento total de caminho quase ilimitado. Por exemplo, se cada componente de caminho tiver 255 bytes, um cliente NFS poderá avaliar até 15 componentes por solicitação (incluindo / caracteres). Como tal, uma cd solicitação para um caminho acima do limite de 4.096 bytes produz uma mensagem de erro "Nome do arquivo muito longo".

Na maioria dos casos, os caracteres Unicode são de 1 byte ou menos, portanto, o limite de 4.096 bytes corresponde a 4.096 caracteres. Se um caractere tiver mais de 1 byte, o comprimento do caminho será menor que 4.096 caracteres. Os caracteres com um tamanho maior que 1 byte contam mais em relação à contagem total de caracteres do que caracteres de 1 byte.

O comprimento máximo do caminho pode ser consultado usando o getconf PATH_MAX /NFSmountpoint comando.

Tamanhos de caracteres discerníveis

O utilitário uniutils Linux pode ser usado para encontrar o tamanho de byte de caracteres Unicode digitando várias instâncias da ocorrência de caractere e visualizando o campo bytes .

Exemplo 1: A maiúscula latina A aumenta em 1 byte cada vez que é usada (usando um único valor hexadecimal de 41, que está no intervalo de 0-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 em cada instância. Isto também pode ser calculado pelos 3 valores de código hexadecimal separados (E5, AD, 97) sob o 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 diaerese 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 ficheiro chamado ÄÄÄ usa 6 bytes dos 255.

Exemplo 4: Um caractere especial, como o 😃 emoji, cai em um intervalo indefinido que excede os 0-3 bytes usados para caracteres Unicode. Como resultado, ele usa um par substituto para sua 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 cai na faixa de 4 bytes, mas pode ir até 7 bytes. Dos mais de mil emojis padrão, aproximadamente 180 estão no Plano Multilíngüe Básico (BMP), o que significa que podem ser exibidos como texto ou emoji nos Arquivos NetApp do Azure, dependendo do suporte do cliente para o tipo de idioma.

Para obter informações mais detalhadas sobre o BMP e outros planos Unicode, consulte Compreender linguagens de volume em arquivos NetApp do Azure.

Impacto dos códigos de caracteres no comprimento dos caminhos

Embora um comprimento de caminho seja pensado para ser o número de caracteres em um nome de arquivo ou pasta, na verdade é o tamanho dos bytes suportados no caminho. Como cada caractere adiciona um tamanho de byte a um nome, diferentes conjuntos de caracteres em diferentes idiomas suportam diferentes comprimentos de nome de arquivo.

Considere os seguintes cenários:

• Um arquivo ou pasta repete o caractere do alfabeto latino "A" 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 caracteres diferentes com tamanhos de bytes diferentes são usados em um nome de arquivo ou pasta, o tamanho de byte de cada caractere leva em conta o comprimento do arquivo ou pasta. Um nome de ficheiro ou pasta com o nome Name字😃 utilizaria 1+1+1+1+3+4 bytes (11 bytes) do comprimento total de 255 bytes.

Conceitos especiais de emojis

Emojis especiais, como um emoji de bandeira, existem sob a classificação BMP: o emoji é renderizado como texto ou imagem, dependendo do suporte ao cliente. Quando um cliente não suporta a designação da 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). 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 sinalizador são traduzidos em imagens de sinalizador em sistemas suportados, mas permanecem como valores de texto em sistemas não suportados. Esses caracteres usam 4 bytes por caractere para um total de 8 bytes quando um emoji de sinalizador é usado. Como tal, um total de 31 emojis de bandeira são permitidos em um nome de arquivo (255 bytes/8 bytes).

Considerações sobre caracteres especiais

Os volumes de Arquivos NetApp do Azure usam um tipo de idioma C.UTF-8, que abrange muitos países/regiões e idiomas, incluindo alemão, cirílico, hebraico e a maioria dos chineses/japoneses/coreanos (CJK). Os caracteres de texto mais comuns em Unicode são de 3 bytes ou menos. Caracteres especiais - como emojis, símbolos musicais e símbolos matemáticos - geralmente são maiores do que 3 bytes. Alguns usam a lógica de par substituto UTF-16.

Se você usar um caractere que os Arquivos NetApp do Azure não suportam, poderá ver um aviso solicitando um nome de arquivo diferente.

Em vez de o nome ser muito longo, o erro realmente resulta do tamanho em bytes dos caracteres ser demasiado grande para o volume de Arquivos NetApp do Azure utilizar através do SMB. Não há solução alternativa nos Arquivos NetApp do Azure para essa limitação. Para obter mais informações sobre a manipulação de caracteres especiais em Arquivos NetApp do Azure, consulte Comportamento de protocolo com conjuntos de caracteres especiais.

Considerações sobre volumes de protocolos duplos

Ao usar os Arquivos NetApp do Azure para acesso de protocolo duplo, a diferença na forma como os comprimentos de caminho são manipulados nos protocolos NFS e SMB pode criar incompatibilidades entre arquivos e pastas. Por exemplo, o Windows SMB suporta até 32.767 caracteres em um caminho (desde que o recurso de caminho longo esteja habilitado no cliente SMB), mas o suporte a NFS pode exceder essa quantidade. Como tal, se um comprimento de caminho for criado no NFS que exceda o suporte do SMB, os clientes não poderão acessar os dados depois que os máximos de comprimento do caminho forem atingidos. Nesses casos, tenha o cuidado de considerar os limites finais inferiores dos comprimentos de caminho de arquivo entre protocolos ao criar nomes de arquivos e pastas (e profundidade do caminho da pasta) ou mapeie os 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 do \\share\folder1\folder2\folder3\folder4. Como resultado, um mapeamento de letra de unidade para Z: pousa na pasta desejada e reduz o comprimento do caminho de Z:\folder1\folder2\folder3\folder4\file para Z:\file.

Next steps

• Compreender línguas em grandes volumes