Resumo

  • O draft-ietf-nfsv4-internationalization-17 admite comportamentos distintos para nomes no NFSv4: octetos opacos, equivalência Unicode, normalização e regras de caixa. Em geral, o cliente não consegue descobrir toda a relação de igualdade adotada pelo servidor.
  • Antes de backup, replicação, failover ou migração, o operador deveria emitir um recibo de equivalência do espaço de nomes com bytes enviados, nomes devolvidos, ambiente, testes de colisão, capacidades observadas e incertezas restantes.

O arquivo abriu; a regra continua escondida

Há mais de uma forma Unicode de representar certas palavras com acentos. Uma aplicação pode enviar um caractere pré-composto; outra, a letra-base seguida de um sinal combinante. Na tela, o nome parece igual. Para uma implementação que compara octeto por octeto, são sequências diferentes.

Se as duas formas abrem o mesmo arquivo, houve uma equivalência em algum lugar. O servidor pode ter normalizado a entrada. Pode ter preservado a forma original e comparado de modo insensível à forma. O sistema de arquivos de base pode ter tomado a decisão. Uma opção local pode ainda ter alterado maiúsculas e minúsculas. A resposta positiva não informa qual dessas explicações vale.

A revisão 17 do projeto de internacionalização do NFSv4 foi publicada em 11 de setembro de 2026, após comentários da Última Chamada do IETF. O documento está ativo no Standards Track e foi encaminhado ao IESG. Ainda é um Internet-Draft: não é RFC nem prova de que um produto tenha implantado o comportamento descrito.

O histórico do texto é central. O relatório do shepherd afirma que as disposições de internacionalização do NFSv4.1 não foram implementadas como planejado. As grandes implementações mencionadas adotaram amplamente a abordagem do NFSv4.0, sem consciência de UTF-8, enquanto recursos conscientes ficaram limitados e experimentais. A revisão parte, assim, do que existe. Interoperabilidade depende da comparação que o sistema realmente faz, e não da intenção que um documento anterior registrou.

Um nome pode ser uma sequência opaca

No regime não consciente de UTF-8, cada componente é uma cadeia opaca de octetos. A comparação deve ser exata. Essa escolha comporta nomes produzidos em codificações antigas e bytes que não formam UTF-8 válido. Ela também impede que o servidor declare equivalência canônica entre duas formas Unicode, pois os caracteres nem sequer participam da decisão.

O resultado tem coerência própria. Os bytes originais mandam e uma atualização de biblioteca não funde automaticamente entradas antigas. Mas uma pessoa pode digitar o mesmo texto visível com outra composição e não localizar o arquivo. A igualdade humana e a identidade do diretório passam a ser coisas diferentes.

Um servidor consciente de UTF-8 pode normalizar antes de armazenar, ou guardar a grafia recebida e aceitar formas canonicamente equivalentes na busca. Pode mapear diferenças de caixa ou tratá-las como iguais na comparação. Implementação, sistema de arquivos e configuração formam juntos a política efetiva; duas exportações do mesmo produto podem divergir.

Também não existe uma única promessa chamada “caixa Unicode”. O mapeamento pode depender de idioma e preferência do usuário. Segundo o projeto, ainda não há um mecanismo geral, pronto para padronização, que comunique todas essas escolhas. A etiqueta “suporta Unicode” não informa se trata de validação, armazenamento, comparação ou apresentação.

A capacidade não revela a equivalência

O atributo fs_charset_cap oferece um dado delimitado. No texto atual, ele sinaliza o comportamento de aceitar apenas nomes UTF-8. O uso histórico de FSCHARSET_CAP4_CONTAINS_NON_UTF8 ficou ambíguo; o projeto orienta servidores a fornecer o complemento e clientes a ignorar a flag. Se o atributo não for suportado, um teste controlado com nome não UTF-8 pode mostrar algo sobre aceitação.

Isso não descobre se existe normalização, qual versão do Unicode a orienta ou quais variantes de caixa coincidem. A pergunta “esta entrada é válida?” difere da pergunta “quais entradas são o mesmo nome?”. Um bit de capacidade responde parcialmente à primeira, não à segunda.

Nem uma bateria de sucessos fecha o contrato. Cada consulta mede um ponto. Um caractere incorporado em versão posterior, uma exceção linguística ou o comportamento específico do armazenamento pode continuar fora da amostra. A documentação do fornecedor também precisa ser separada da observação: a descrição pode parar na camada NFS quando a comparação real ocorre abaixo dela.

Listar não é enumerar todas as equivalências

READDIR devolve a grafia apresentada pelo servidor. Não devolve todas as grafias que LOOKUP aceitaria para alcançar o mesmo filehandle. Um servidor pode preservar um nome e reconhecer outro como equivalente. Portanto, baixar a lista e compará-la no cliente não reproduz necessariamente a semântica do servidor.

Caches negativos agravam a diferença. Um cliente pode guardar “não existe” segundo sua própria regra e continuar negando um nome que o servidor resolveria por equivalência. Pode também pular LOOKUP porque nenhuma entrada de READDIR parece coincidir localmente, perdendo um objeto que seria encontrado. O projeto pede que clientes estejam preparados para normalização, mas não presumam que ela ocorrerá.

O tempo modifica o cenário. Classes de equivalência canônica podem ganhar membros quando o Unicode acrescenta caracteres. O projeto prefere comparação indiferente à forma em vez de impor uma forma de armazenamento, em parte porque nomes de arquivo duram muito. Preservar os bytes continua necessário, porém não garante que uma plataforma futura os julgue da mesma maneira.

Migrar é trocar quem julga o nome

Planos de migração medem volume, quantidade, permissões, datas e hashes. Faltam-lhes, muitas vezes, as relações de igualdade. Ao recriar uma entrada no destino, uma nova pilha decide o que aceita e o que funde.

Se a origem distingue duas sequências e o destino as considera uma só, ocorre colisão ou sobrescrita. Se a origem aceita duas formas para a mesma entrada e o destino exige correspondência exata, a variante usada pelo aplicativo deixa de funcionar. Se o destino recusa bytes históricos, um backup pode conservar o conteúdo sem conseguir restaurar seu endereço. Se muda a regra de caixa, caminhos anteriormente distintos competem.

Abrir alguns arquivos conhecidos favorece justamente os nomes menos arriscados: atuais, frequentes, produzidos pelas bibliotecas e teclados de hoje. Não alcança o acervo herdado, combinações raras nem variantes que ninguém percebeu porque o servidor sempre as reconciliou.

Na restauração, a falha pode aparecer depois da desativação da origem. Na replicação, uma fusão silenciosa pode parecer convergência. No failover, o conteúdo está no secundário, mas o programa perdeu a maneira de chamá-lo.

O recibo de equivalência do espaço de nomes

Uma decisão consequente precisa de um artefato curto que outro operador consiga examinar. Chamemo-lo de recibo de equivalência do espaço de nomes. Trata-se de uma proposta editorial de governança, não de requisito do projeto IETF.

O recibo identifica versão do NFS, implementação e versão do servidor, sistema de arquivos quando conhecido, opções de exportação e montagem, sistema operacional, biblioteca Unicode e data. Cada componente testado é preservado como bytes exatos e como visualização segura. A visualização auxilia pessoas; os bytes impedem que a ferramenta de registro normalize a própria prova.

O corpus começa nos nomes realmente existentes e inclui pares orientados ao risco: forma composta e decomposta, variantes de caixa pertinentes, bytes não UTF-8 herdados e caracteres sensíveis a versões. Criação e colisão são testadas de maneira não destrutiva em área isolada. Registra-se se LOOKUP entrega o mesmo filehandle, o que READDIR apresenta, se a criação é aceita, o que informa fs_charset_cap e se o resultado persiste sem o cache negativo.

Origem e destino devem executar ensaios comparáveis. Cada linha separa observação, afirmação do fornecedor e inferência ainda não comprovada. Colisões, recusas e ambiguidades recebem responsável e tratamento: renomeação reversível, escape, isolamento, camada de compatibilidade ou aceitação consciente. Qualquer transformação preserva o mapa entre bytes originais, nome novo e identidade do conteúdo depois que a origem for desligada.

O escopo precisa permanecer exato. Conteúdo de link simbólico é opaco sob outra regra; nomes de domínio não ASCII usam U-labels; tipos de string do NFS não são uniformes. O recibo não certifica “Unicode em geral”. Ele registra relações específicas observadas em um ambiente específico.

O limite da evidência

O RFC 6943 mostra que comparação inconsistente de identificadores pode causar falsos positivos, falsos negativos, negação de serviço e, em certos sistemas, elevação de privilégio. Isso não é relato de incidente no NFS, e o projeto não faz essa alegação. É razão suficiente para incluir equivalência de nomes em revisão de segurança quando caminhos participam de autorização, execução ou guarda de registros.

A conclusão defensável é estreita: um espaço de nomes no lado do servidor resolveu determinada sequência de bytes, naquele momento e sob aquela configuração. Não estabeleceu identidade universal de caracteres, uma relação portátil de igualdade nem a promessa de que outro servidor repetirá o julgamento. O nome parece rótulo; na prática distribuída, também é resultado de política.

Fontes