Resumo

  • Cada STOU pede uma nova alocação no diretório corrente. Repetir a transmissão pode produzir vários pathnames, mesmo quando o remetente acredita estar repetindo um único trabalho.
  • O pathname informado em 125 FILE: ou 150 FILE: prova a escolha feita pelo servidor antes da transferência; uma resposta posterior prova outro fato. Nenhuma das duas determina automaticamente qual arquivo deve sobreviver a uma série de tentativas.
  • REST seguido de STOU é permitido por alguns servidores, mas não recomendado e semanticamente indefinido: um marcador de reinício não transforma um novo pathname no mesmo arquivo parcial.

Três tentativas, três destinos

A primeira conexão de dados caiu no meio. O cliente havia recebido um nome do servidor, mas não recebeu uma conclusão. Sua política automática tentou novamente. Como o pedido era STOU, o segundo início não reutilizou necessariamente o primeiro pathname; o servidor escolheu outro que não colidia no diretório corrente. Uma nova interrupção levou a uma terceira tentativa e a uma terceira escolha.

Para o remetente, as três operações podiam representar “o mesmo arquivo”. Para o protocolo, eram três pedidos de armazenamento único, cada um com sua própria alocação e seu próprio resultado. O primeiro pathname podia guardar um prefixo parcial. O segundo podia não ter conteúdo algum. O terceiro podia ter recebido todos os bytes. Também era possível que o servidor tivesse removido um deles ou que nenhuma entrada persistisse. Este é um cenário de análise, não o relato de uma falha observada; o comando não autorizava o cliente a preencher essas lacunas com uma história conveniente.

A diferença surge porque STOU resolvia colisão, não repetição. Sua promessa era escolher um pathname ainda não ocupado naquele diretório. Quanto melhor cumpria essa promessa a cada nova tentativa, mais nomes distintos uma política de repetição podia produzir. A ausência de colisão não dizia, por si só, se dois pathnames levavam ao mesmo arquivo armazenado.

O recibo de nome não encerrava a transferência

O RFC 959, de outubro de 1985, padronizou STOU <CRLF> sem argumento de pathname. O estado da sessão podia já ter selecionado o diretório corrente; a escolha do nome do novo arquivo cabia ao servidor. O documento dizia que esse nome deveria ser único em relação àquele diretório, não em todo o servidor, em toda a Internet ou por todo o futuro.

O RFC 959, porém, confundiu a fase em que o nome precisava ser devolvido. Seu texto falava em uma resposta “250 Transfer Started”, embora 125 e 150 fossem os códigos preliminares de início e 250 significasse ação de arquivo concluída. A própria tabela de STOU colocava 125 ou 150 antes de 226 ou 250. Para uma única tentativa já era uma inconsistência; numa sequência de repetições, ela ameaçava misturar qual nome pertencia a qual começo e qual resultado pertencia a qual fim.

O RFC 1123, de outubro de 1989, corrigiu a ordem e a forma. O pathname efetivamente escolhido deveria aparecer antes da transferência, como 125 FILE: pppp ou 150 FILE: pppp. O marcador fixo FILE: retirava o nome da prosa variável das respostas e dava ao cliente uma estrutura que podia ser analisada por máquina.

Mas a correção não converteu o recibo preliminar em prova de conclusão. “O arquivo que será escrito” ainda podia falhar. Uma resposta posterior como 226 ou 250 informava o resultado da transferência no nível do FTP; 425, 426, 451, 551, 552 e outros códigos preservavam falhas distintas. Nem mesmo um final positivo provava retenção futura, backup, imutabilidade ou visibilidade permanente.

Em uma repetição, portanto, o sistema precisava guardar cada par sem fundi-los: o pathname da tentativa e o resultado daquela tentativa. Conservar só o último FILE: apagava os arquivos registrados sob os nomes anteriores. Conservar só o último sucesso apagava a possibilidade de que outro nome tivesse recebido conteúdo completo antes de uma falha na resposta.

Um prefixo parcial não reconhecia seu sucessor

É tentador pensar que a segunda tentativa simplesmente continuaria o que a primeira começou. O RFC 3659 mostra por que essa composição não era automática. Ele estendeu REST para reinício em modo stream e indicou que o comando de transferência seguinte deveria normalmente ser RETR ou STOR.

Um servidor podia aceitar APPE ou STOU depois de REST; o texto não proibia toda implementação. Ainda assim, a combinação REST→STOU não era recomendada e seu significado foi declarado indefinido. Guardar o restante de um arquivo sob um nome único recém-criado raramente servia ao objetivo de retomar um arquivo já existente.

O marcador de reinício descreve uma posição compartilhada numa representação. Para que ele tenha sentido, as partes precisam saber qual arquivo continua do outro lado dessa posição. STOU faz a pergunta oposta: qual pathname novo o servidor pode alocar agora? O fato de o remetente oferecer os bytes restantes não prova que o novo pathname aponta para o arquivo parcial da tentativa anterior.

Isso deixa pelo menos três riscos. O servidor pode gravar apenas o sufixo no novo pathname. O cliente pode acreditar que o novo nome contém o arquivo inteiro. Uma rotina posterior pode combinar ou apagar arquivos usando uma correspondência entre pathnames que o protocolo nunca afirmou. A possibilidade de uma implementação aceitar a sequência não fornece uma semântica interoperável para resolver esses riscos.

A outra palavra “Unique” não fazia deduplicação de conteúdo

O RFC 3659 também definiu o fato Unique= em listagens legíveis por máquinas. Ele responde se dois pathnames apontam para o mesmo arquivo armazenado: tokens iguais indicam o mesmo arquivo. O valor é opaco, sensível a maiúsculas e minúsculas, e sua consistência precisa durar pelo menos a conexão de controle, não para sempre.

Essa evidência não é o nome devolvido por STOU. A unicidade do comando impede uma colisão de pathname no diretório corrente. O fato Unique= compara se pathnames já existentes levam ao mesmo arquivo armazenado. Um mesmo arquivo pode ter mais de um nome; nomes novos e diferentes podem levar a arquivos distintos, mesmo quando nasceram de repetições do mesmo conteúdo do lado do cliente.

Também não se pode transformar o token em hash do arquivo. O documento não afirma igualdade de conteúdo, estabilidade global nem idempotência de solicitações. Ele adverte, inclusive, que identificadores de sistema de arquivos capazes de contornar proteções não devem ser expostos como Unique=. Uma pista de comparação não deveria virar capacidade de acesso.

Assim, nem o pathname novo nem o token resolvem sozinhos o leque de tentativas. O primeiro localiza uma entrada sem colisão. O segundo pode dizer, durante seu período de consistência, se dois nomes levam ao mesmo arquivo armazenado. Para saber se duas tentativas transportavam o mesmo conteúdo, é preciso outra evidência; o FTP não autoriza deduzir isso do adjetivo “unique”.

Antes da repetição, havia um problema de pathname estrangeiro

Essa escolha pelo servidor nasceu de uma dificuldade mais antiga que a automação de novas tentativas. O RFC 172, de junho de 1971, descrevia o arquivo como dados identificados por um pathname dentro de um sistema. O FTP padronizava operações, mas não padronizava as convenções de nomes. O usuário precisava formular um pathname válido para a máquina remota.

Um STOR normal carregava essa escolha e sua consequência. Se o pathname existisse, o conteúdo poderia ser substituído; se não existisse, um arquivo poderia ser criado. O cliente atravessava a rede com dados e, ao mesmo tempo, tentava falar a língua do espaço de nomes alheio. O protocolo não transferia para ele a proteção do sistema residente: acesso seletivo continuava subordinado ao host.

Em 1973, o RFC 505 considerou como alguém poderia enviar um arquivo a um usuário de outro host sem conhecer sua senha. Uma proposta usava um diretório de pool. O arquivo ficava numa área intermediária, o destinatário era avisado e depois podia copiá-lo, sem entregar ao remetente o diretório pessoal nem permitir que ele consumisse diretamente sua alocação.

A operação proposta POOL id name ainda aceitava um nome desejado, mas o servidor acrescentaria prefixo ou sufixo para torná-lo único no pool. A ideia já separava destinatário alegado, depósito, adaptação de nome e notificação. Não há base para declarar que POOL foi amplamente implantado ou que virou diretamente o comando posterior; sua relação é uma linhagem de proposta, não uma história de adoção.

O novo comando escolheu colisão mínima, não efeito idempotente

O RFC 949, publicado em julho de 1985, propôs STOU para filas como impressão, fax e perfuração de cartões. Foram consideradas mudanças em STOR, um novo argumento e um caso especial sem argumento. Criar outro comando pareceu preferível a reabrir a interpretação de um verbo já estabelecido, além de ser mais simples para os despachantes por nome de comando.

O comportamento seria semelhante ao de STOR, exceto pela criação no diretório corrente sob nome único. O documento também decidiu que o remetente precisava saber o nome escolhido; a divulgação não seria opcional. Era um desenho para entregar um trabalho sem obrigar o cliente a administrar colisões do pool.

Ele não prometia que duas solicitações iguais produziriam o mesmo resultado. Na verdade, o objetivo de evitar colisões empurrava solicitações repetidas para nomes diferentes. Idempotência exigiria um identificador estável da intenção, uma regra de repetição ou uma comparação de conteúdo que não fazia parte de STOU.

O RFC 949 também afirmou que o comando não deveria contornar controle de acesso, autenticação ou contabilidade. Uma política de repetição não podia usar o fato de obter nomes novos como prova de autorização contínua, nem como licença para consultar ou excluir qualquer entrada do diretório.

Um registro não contava quantos servidores aceitavam a tentativa

O RFC 5797 e o atual registro de comandos e extensões FTP da IANA mantêm STOU como comando base opcional, referenciado pelos RFCs 959 e 1123. O objetivo principal do registro é evitar conflitos de nomes, não medir implantação, qualidade ou sucesso.

O código base é um marcador imutável para comandos básicos e não deve aparecer como linha FEAT. Uma entrada no registro não prova que um servidor concreto anuncia ou implementa a operação; somente o comportamento observado da sessão pode fornecer essa evidência. Também não há fundamento para estimar uso presente a partir da permanência do nome na tabela.

E a repetição podia ampliar riscos que a escolha de nome não tratava. O RFC 2577 documentou que o FTP padrão enviava senhas, comandos e dados sem criptografia, além de descrever roubo e substituição da conexão de dados. Três pathnames distintos não autenticavam três conteúdos, não validavam o par de dados e não provavam que todas as tentativas vieram da mesma origem.

STOU fazia algo menor e útil: dava ao servidor a escolha de uma vaga não conflitante e fazia o cliente aprender o nome. Em uma repetição, essa mesma precisão obrigava o operador a admitir a multiplicidade resultante. Um novo nome era uma nova alocação, não a reparação silenciosa da anterior.