Summary

  • A RFC 775 descreveu quatro comandos experimentais de FTP criados pela BBN para montar, remover e percorrer diretórios durante manutenção remota.
  • O servidor precisava devolver o nome absoluto do diretório recém-criado. Em TOPS-20, o nome curto usado na criação podia não servir para acessá-lo em seguida.

Parece conversa de repartição: a pasta existe, só não atende pelo nome escrito no pedido. A RFC 775 registrou esse embaraço em dezembro de 1980. Num servidor TOPS-20, a sequência XMKD MYDIR seguida de XCWD MYDIR podia terminar em erro. O primeiro comando criava um diretório; o segundo tentava encontrá-lo por um nome que o sistema não reconhecia naquele contexto.

A origem da proposta foi o trabalho da BBN de instalar e manter software em vários DEC PDP-11 com UNIX para um projeto de manutenção remota da ARPA. Copiar os arquivos de uma instalação era insuficiente quando a estrutura de diretórios precisava acompanhá-los. A equipe acrescentou quatro comandos ao servidor FTP: XMKD para criar, XRMD para remover, XPWD para mostrar o diretório corrente e XCUP para subir ao diretório pai. O último poupava o cliente de adivinhar a grafia local de “volte um nível”.

O alvo não era só o UNIX. TOPS-20 e Multics também tinham diretórios em árvore, mas não usavam necessariamente a mesma sintaxe de caminhos. Imagine o cliente conectado a <DFRANKLIN> no TOPS-20. Ele envia XMKD MYDIR; o servidor cria <DFRANKLIN.MYDIR>. O nome fornecido na ordem expressava a intenção de criar um filho. O nome que serviria de endereço depois era outro. A diferença aparece justamente quando um programa tenta automatizar a cópia de uma árvore inteira.

A saída foi tornar a resposta tão importante quanto a ordem. Depois de criar o diretório, o servidor deveria enviar uma linha 257 com o nome absoluto entre aspas. A RFC exemplifica o caso UNIX com 257 "/usr/dm/child" directory created; em TOPS-20, a resposta traz a notação de TOPS-20. Se houver aspas dentro do próprio nome, elas aparecem duplicadas na resposta. Esse detalhe permite ao cliente interpretar a string sem partir o caminho no lugar errado. Pedir a criação não confere ao cliente o poder de inventar a identidade do objeto criado.

Com o nome devolvido, um programa consegue entrar no novo diretório, levar os arquivos, construir os subdiretórios e retornar ao pai. Sem ele, o arquivo pode até atravessar a rede perfeitamente, mas o programa se perde no endereço de entrega. As quatro ordens formam um pequeno kit de navegação para transportar estruturas, não só conteúdos.

A RFC também definiu o que fazer se a pasta já existir. A implementação da BBN tratava a situação como erro, exemplificado por uma resposta 521 sem criar nada. Na tabela de códigos, o texto separa o FTP mais antigo em uso das sugestões para o protocolo mais recente da RFC 765. O 257 era novo na primeira coluna; 251 aparecia como proposta na segunda. A história do protocolo tem versões, e os números carregam esse contexto.

A RFC 765 declarava que o FTP deveria resguardar o usuário das diferenças entre sistemas de arquivos, mas reconhecia a falta de uma convenção universal para caminhos. A BBN respondeu com uma regra prática: deixe cada servidor dar o nome válido no próprio sistema. Em 1985, a RFC 959 incluiu MKD, RMD, PWD e CDUP como comandos opcionais, sem o X experimental. A pasta deixou de ser apenas recipiente de arquivos. Passou a ser parte do diálogo que permitia chegar até eles.