Resumo

  • O FTP dividiu a renomeação em RNFR e RNTO; o 350 da primeira ordem aceitava uma etapa pendente, mas não afirmava que o nome havia mudado.
  • A RFC 3659 tornou visíveis superfícies distintas de permissão na origem e no diretório de destino, além de um fato Unique opcional para comparar o objeto sob nomes diferentes.
  • A sequência padroniza estados e evidências, sem prometer atomicidade, durabilidade, política de colisão, segurança contra falhas ou disponibilidade num servidor atual.

O arquivo continuava no nome antigo

Imagine um painel que recebe 350 Requested file action pending further information depois de RNFR antigo. Como o código é positivo, o evento fica verde e a automação seguinte parte do pressuposto de que novo já existe.

Esse pressuposto chega cedo demais. A RFC 959 define 3xx como resposta positiva intermediária: a ordem foi aceita, porém a ação pedida permanece em suspenso à espera de mais informação. Para uma renomeação, essa informação é o caminho novo enviado em RNTO.

A RFC 765 já descrevia a construção. RNFR especifica o arquivo a renomear e deve ser seguido imediatamente por RNTO; o segundo associa um novo caminho ao arquivo indicado pela ordem anterior. É o par que causa a renomeação.

O protocolo não tratou o intervalo como ruído. Deu-lhe uma classe de resposta própria, permitindo dizer algo positivo e ainda assim não confundir progresso com conclusão.

Uma memória curta dentro da conexão

RNFR e RNTO formam um grupo sequencial. Se algum passo falha, as especificações mandam repetir a sequência desde o início. O servidor guarda contexto suficiente para que a próxima ordem de destino faça sentido naquela conexão de controle.

Isso não equivale a um identificador durável de transação. Também não prova que a origem ficou bloqueada, que o destino foi reservado ou que uma política futura não mudará. A exigência de imediatidade limita a associação: o RNTO refere-se ao arquivo do RNFR imediatamente anterior. Sem a ordem esperada, pode haver 503 Bad sequence of commands.

Por isso, uma trilha precisa preservar sessão e ordem, não apenas strings de comandos. Duas linhas com origem e destino, recolhidas de conexões diferentes ou sem posição verificável, não recompõem a máquina de estados.

Há uma diferença documental entre proposta, aceitação pendente e resultado. O cliente propôs uma origem; o servidor aceitou guardá-la para a continuação; somente a resposta final ao destino informa se a mutação terminou.

Dois códigos positivos, duas responsabilidades

Na RFC 959, 2xx significa conclusão positiva: a ação pedida terminou com êxito e uma nova solicitação pode começar. 250 significa que a ação sobre arquivo está correta e concluída. 350, ao contrário, incorpora a dependência de informação adicional.

Agrupar os dois como “sucesso” retira justamente a semântica de estado que os números carregam. Depois de 350, cabe ao cliente completar a sequência corretamente. Depois de 250, há evidência de conclusão no nível do protocolo.

Se a última resposta se perde, o resultado fica indeterminado para o cliente. A conduta segura é observar o namespace antes de repetir uma operação com efeito. O 350 antigo não é um recibo que autorize continuar após qualquer falha; a recuperação prevista reconstrói a sequência desde a origem.

Poder nomear a origem não autoriza qualquer destino

A RFC 3659 acrescentou fatos de listagem que ajudam a separar os lados da operação. O indicador f num objeto diz que ele pode ser objeto de RNFR para o usuário FTP atual. O indicador c num diretório diz que arquivos podem ser criados ali e que um RNTO para nomes naquele diretório provavelmente terá êxito.

Uma capacidade está ligada ao objeto de origem; a outra, ao contêiner de destino. Elas não formam uma autorização genérica de edição. Um usuário pode ter poder para liberar um nome sem poder criar nomes em todos os espaços possíveis.

“Provavelmente” também importa. O fato perm descreve uma expectativa no momento da observação, não reserva o destino nem garante o resultado final. Concorrência e política continuam existindo, e a resposta à ordem continua necessária.

Uma identidade opcional por baixo do caminho

A mesma extensão definiu o fato opcional Unique. Quando fornecido, caminhos que apontam para o mesmo arquivo subjacente devem compartilhar um valor opaco; arquivos diferentes devem ter valores diferentes. A consistência deve durar pelo menos a conexão de controle.

O exemplo da RFC começa com mlst.c e um valor Unique. O cliente recebe 350 para RNFR mlst.c, envia RNTO list.c e recebe 250. Depois, list.c aparece com o mesmo valor. O nome mudou; a pista limitada de identidade oferecida pelo servidor permaneceu.

Não se deve transformar a pista em promessa universal. Servidores não são obrigados a oferecer um conjunto específico de fatos MLSx. Unique não é hash de conteúdo, identificador global nem valor permanente. O exemplo apenas mostra como duas evidências podem se complementar: a resposta final atesta a ação protocolar, e o fato opcional reforça que os nomes, antes e depois, se referem ao mesmo objeto subjacente dentro do seu escopo.

Um comando obrigatório não é um contrato de filesystem

A RFC 1123 manteve RNFR e RNTO entre os requisitos de comandos FTP. A RFC 5797 organizou os dois como comandos básicos obrigatórios, e o registro de comandos FTP da IANA preserva as entradas.

Esses documentos coordenam uma linguagem interoperável. Não dizem se leitores concorrentes veem a troca de forma atômica, se um destino existente é sobrescrito, quando a alteração chega ao armazenamento durável, o que ocorre num crash ou como caminhos entre sistemas de arquivos são tratados. Tampouco demonstram que um servidor público específico permite o par hoje.

O compromisso normativo é menor e mais preciso: o estado de origem pendente e a renomeação concluída não são a mesma coisa. A implementação do armazenamento permanece uma questão separada.

Entre dois nomes

APIs modernas também aceitam propostas antes de efetivar mudanças. O bom desenho dá nome a esse estado intermediário, informa sua validade, liga-o a uma sessão ou transação e reserva a palavra “concluído” para uma prova de conclusão.

Também separa autoridade sobre a origem, autoridade para criar no destino e identidade do objeto. Sem essa divisão, uma interface simples demais pode tanto enganar o auditor quanto ampliar uma delegação.

O 350 do FTP não era um sucesso de qualidade inferior. Era um sucesso precisamente não final. O arquivo entrara numa sequência de protocolo, não em outro caminho. A renomeação ainda não tinha acontecido — e o código dizia isso.

Fontes