Resumo

  • Uma ação de arquivo no FTP atravessava duas conexões. A conexão de dados levava os bytes; a de controle mantinha o estado do comando. Uma resposta 1yz era positiva, porém preliminar, e exigia outra resposta.
  • O fechamento da conexão de dados podia resultar de EOF normal, ABOR, mudança da especificação de porta, encerramento do controle ou erro irrecuperável. O mesmo evento de transporte não decidia entre essas causas.
  • Num ABOR durante transferência ativa, 426 encerra negativamente a transferência original e o 226 seguinte encerra positivamente o comando de cancelamento. O último código não pode herdar a autoria do primeiro trabalho.

O fim visível não era o fim contábil

Uma barra de progresso chega a cem por cento. O TCP fecha de modo ordenado. O nome do arquivo aparece no servidor. É natural que uma interface reúna os três sinais sob “concluído”. O FTP, porém, manteve uma divisão que impede essa conclusão automática.

Comandos e respostas numeradas trafegavam numa conexão de controle relativamente duradoura. Listagens e arquivos usavam conexões de dados separadas e temporárias. O processo de dados observava abertura, octetos, EOF e falha de transporte. O interpretador de protocolo conhecia o comando em curso, a resposta preliminar já emitida e a resposta que encerraria a ação.

Os dois registros não eram cópias do mesmo recibo. O caminho de bytes podia ficar silencioso sem explicar por quê. O controle podia declarar falha mesmo depois de muitos bytes ou podia desaparecer depois de um efeito local já ocorrido. A arquitetura só permanecia auditável se essas duas linhas fossem preservadas.

A diferença surgiu antes dos códigos atuais

A RFC 354, de julho de 1972, já separava 252 FTP transfer completed correctly de 452 FTP: File transfer incomplete, data connection closed.

As duas situações podiam terminar com a conexão de dados fechada. O que mudava era o juízo do servidor sobre a ação de arquivo. Assim, a especificação antiga já recusava a regra operacional “socket fechado sem reset significa transferência bem-sucedida”.

O FTP atendia máquinas com representações, tamanhos lógicos, registros e sistemas de armazenamento diferentes. O servidor coordenava o interpretador com um processo de transferência e uma operação local. A quantidade de bytes observada na rede não podia narrar conversão, gravação e resultado do comando ao mesmo tempo.

Faltava uma gramática numérica mais adequada a programas. Textos variavam entre servidores; o cliente precisava descobrir, pelo código, se devia esperar, mandar informação adicional, iniciar outra solicitação ou planejar uma nova tentativa.

A primeira casa passou a expressar estado

A RFC 640, publicada em 1974, reorganizou as respostas. 1yz tornou-se positivo preliminar: a ação foi iniciada, permanece incompleta e outra resposta virá. 2yz é conclusão positiva. 3yz aceita o passo anterior, mas aguarda informação. 4yz e 5yz encerram negativamente a solicitação, com consequências distintas para repetição.

Por isso, “positivo” nunca foi um único tipo de sucesso. 150 pode autorizar o cliente a cuidar da conexão de dados e, simultaneamente, proibi-lo de encerrar o comando na sua máquina de estados.

A RFC 640 também antecipou a resposta preliminar. O servidor podia enviá-la quando a transferência fosse possível e a conexão existisse ou estivesse prestes a ser tentada. Isso reduzia espera, mas limitava a prova: prontidão e tentativa não eram estabelecimento, muito menos conclusão.

Depois de 125 ou 150, ainda faltava a última resposta

A RFC 765 e a RFC 959, de 1985, mantiveram o percurso. A RFC 959 admite no máximo uma resposta 1yz por comando e determina que uma resposta de conclusão venha depois.

Nas ações de arquivo, 125 informa que a conexão de dados já está aberta e a transferência começa. 150 diz que o estado do arquivo está correto e que o servidor está para abrir a conexão. A terminação pode ser 226 ou 250, ou uma falha aplicável como 425, 426, 451, 551 ou 552.

Uma captura com 150, o total previsto de bytes e FIN ainda não contém o resultado FTP se perdeu a resposta final. Do outro lado, um código negativo não deixa de existir porque o contador fechou no valor esperado. Divergência entre as provas é informação, não ruído.

O cliente normalmente espera a conclusão antes de enviar o próximo comando comum porque o estado anterior continua aberto. ABOR e STAT são difíceis justamente por precisarem chegar ao interpretador enquanto o trabalho está em andamento.

Uma conexão podia fechar por razões incompatíveis

A RFC 959 enumera causas para o servidor fechar o canal de dados: término normal da transferência, recebimento de ABOR, alteração da especificação de porta, fechamento legal ou anormal da conexão de controle e erro irrecuperável.

Todas podem aparecer como “socket encerrado” no transporte. Não significam a mesma coisa para o comando. Um FIN ordenado não prova que o limite pretendido do arquivo foi atingido, que o efeito local foi aceito ou que o servidor não estava obedecendo a um cancelamento.

No modo Stream, o fechamento pode marcar o fim do arquivo. Isso é enquadramento do fluxo, não ampliação do recibo. A fragilidade fica evidente na retomada: sem o contexto do controle, término normal e interrupção prematura podem produzir o mesmo vestígio.

O monitor deve, portanto, guardar “EOF/fechamento observado nos dados” e “ação FTP encerrada com código X” como eventos diferentes. Proximidade no relógio não lhes dá a mesma autoridade.

O 226 final podia confirmar o cancelamento

Se o serviço anterior já acabou quando chega ABOR, não há mais o que interromper. O servidor ainda pode devolver 226 para dizer que processou o comando de aborto. Essa resposta pertence ao ABOR, não reabre a conclusão do arquivo anterior.

Quando a transferência permanece ativa, a RFC 959 prescreve duas respostas. Primeiro, 426 registra que a conexão foi fechada e a transferência original foi abortada. Depois, 226 registra que o comando ABOR foi processado com sucesso.

Há dois resultados:

  1. transferência original → conclusão negativa por aborto (426);
  2. solicitação de aborto → conclusão positiva (226).

Um coletor que guarda apenas o último código concede sucesso à ação errada. Um coletor que prende os dois ao comando inicial perde o sucesso real do cancelamento. Ordem e proprietário da resposta são parte do dado.

O alcance de 226 parava na fronteira do protocolo

No caminho normal, 226 declara que a conexão de dados está fechando e que a ação solicitada foi bem-sucedida no FTP. Não leva hash de conteúdo, identidade de versão nem promessa de armazenamento durável. Não diz que houve backup, que permissões futuras permanecerão, que outra aplicação consumiu o arquivo ou que uma obrigação comercial foi cumprida.

Essas conclusões exigem recibos próprios: digest para conteúdo, registro de sincronização para persistência, identificador imutável para versão e confirmação da aplicação para uso posterior.

A ausência de 226 também não apaga efeitos. O servidor pode terminar uma gravação e perder o controle antes de a resposta chegar. Repetir cegamente pode duplicar ou sobrescrever. O estado correto é “resultado FTP desconhecido”, não “operação inexistente”.

O histórico de controle fazia parte do dossiê

Um registro mínimo preserva comando e ordem, 125/150, ponto de dados, resultado da abertura, bytes, EOF, causa de fechamento quando conhecida, respostas finais em sequência e o tempo relativo de ABOR ou STAT.

Também guarda separadamente fatos não certificados pelo FTP: representação e modo, resolução do caminho, efeito no arquivo, persistência, hash e identidade do objeto. Complementar não significa intercambiável.

Um booleano done não basta. É preciso distinguir preliminar aceito, conexão pendente, dados ativos, dados fechados aguardando final, transferência positiva, transferência negativa, aborto solicitado, transferência abortada, aborto processado e resultado de controle desconhecido.

Depois que esses estados viram uma única etiqueta, não há como recuperar a ação à qual o último código pertencia. A perda irreversível é semântica.

Fontes e limite da evidência

A narrativa usa as RFC 354, RFC 542, RFC 640, RFC 765, RFC 959 e RFC 1123. Elas sustentam as classes de resposta, as conexões separadas, os motivos de fechamento e a sequência de ABOR.

A RFC 1123 observou em 1989 que retomada, ABOR e modo Block eram úteis, porém pouco implementados. Essa é uma observação histórica, não uma medição atual. As fontes não provam comportamento ou conformidade de produtos atuais nem durabilidade de um sistema de arquivos.