Resumo

  • ALLO levava ao servidor uma estimativa em bytes lógicos antes de STOR ou APPE, com um segundo número opcional para a maior unidade de registro ou página.
  • Em servidores que não precisavam de alocação antecipada, a operação devia ser nula; o 202 era conclusão positiva porque a ordem era supérflua, não porque o espaço estivesse garantido.
  • A comprovação útil precisava atravessar toda a sequência: resposta preparatória, conexão de dados, resposta final, estado de quota e conteúdo efetivamente armazenado.

Um pedido de capacidade em uma rede de discos diferentes

Enviar um arquivo grande sem saber se há espaço parece desperdício. O cliente conhece o tamanho e gostaria de avisar o destinatário. Se a máquina remota puder reservar blocos, a preparação reduz o risco de descobrir o limite no fim. Mas a internet inicial não ligava cópias do mesmo sistema operacional. Ligava hosts com modelos de arquivo e alocação incompatíveis.

O RFC 354, de 1972, registrou essa diversidade dentro da própria definição de ALLOCATE (ALLO). Alguns servidores poderiam exigir a ordem para reservar armazenamento suficiente ao novo arquivo. O argumento decimal representava bytes conforme o tamanho de byte em uso e deveria ser seguido por STORE ou APPEND.

Na frase seguinte vinha a exceção estrutural: servidores que não exigissem a declaração antecipada do tamanho máximo deveriam tratar ALLO como operação nula. A especificação não obrigava uma máquina a simular uma política de disco que ela não possuía. O cliente expressava necessidade; o servidor preservava a autoridade sobre a forma local de satisfazê-la.

O RFC 765, publicado em 1980, acrescentou a noção de bytes lógicos e um segundo campo. Arquivos com estrutura de registro ou página poderiam precisar informar o maior registro ou a maior página, também em bytes lógicos. A sintaxe separava o segundo inteiro por espaço, R, espaço. Um servidor interessado só nessa medida deveria aceitar um primeiro valor fictício e ignorá-lo.

Esses detalhes impedem uma equivalência apressada. O número de ALLO não é leitura do espaço livre. Não é necessariamente o número de blocos do sistema de arquivos, o débito de quota, os octetos comprimidos na rede nem o tamanho durável depois de conversões. É uma declaração na representação FTP que o servidor pode usar, se seu ambiente precisar.

A resposta que concluía positivamente uma não operação

Em 1985, o RFC 959 manteve ALLO com um inteiro obrigatório e a forma opcional R mais outro inteiro. Manteve também a regra de que STOR ou APPE deveria vir depois e a recomendação de NOOP para servidores sem alocação antecipada.

O tratamento de respostas revela o objetivo. Uma ordem como TYPE ou ALLO, executada com sucesso sem oferecer informação nova ao processo do usuário, recebe 200. Quando ALLO não é implementada porque não tem relevância para o sistema local, ainda se deseja uma conclusão positiva. Assim, um cliente simples sabe que pode continuar seu curso. O código indicado é 202, acompanhado do exemplo “No storage allocation necessary”.

A descrição geral de 202 diz que a ordem não foi implementada e é supérflua naquele site. Isso não equivale a erro escondido. O servidor assume, de forma explícita, que a ação pedida não é condição para a próxima etapa. A compatibilidade tem êxito justamente porque ele não precisa alegar que reservou alguma coisa.

O protocolo diferencia esse caso de 502, usado para ação não específica do site que não foi implementada, e de 504, associado a parâmetro não implementado. A classificação pergunta se a ausência impede a intenção do usuário. Para ALLO desnecessário, a resposta é não.

Também seria excessivo ler 200 como certificado universal de espaço. Um servidor pode de fato executar uma reserva, mas o código não informa quantidade física, duração, competição, política de quota ou garantia de persistência. O RFC o situa onde a execução bem-sucedida não dá nova informação. Sem telemetria local, o cliente só sabe que a fase preparatória terminou.

O arquivo ainda precisava enfrentar STOR

ALLO não carrega dados. STOR pede ao servidor que aceite o fluxo da conexão de dados e o guarde sob o nome indicado. Se o arquivo já existir, ele deve ser substituído pelo conteúdo recebido; se não existir, deve ser criado. Nesse momento, intenção e infraestrutura se encontram.

As respostas distinguem começo e fim. 125 informa que a conexão de dados já está aberta e a transferência está começando. 150 anuncia que o estado do arquivo é adequado e a conexão será aberta. São respostas preliminares. Uma conclusão positiva pode vir como 226 ou 250; falhas de conexão, processamento, caminho, autorização e armazenamento mantêm códigos separados.

452 significa que a ação solicitada não foi realizada por falta de espaço no sistema. 552 informa que a ação sobre o arquivo foi abortada porque a alocação do diretório ou conjunto de dados foi excedida. Receber 202 antes de uma dessas falhas não é incoerência. O servidor afirmou que reservar antecipadamente era desnecessário, não que escrever depois seria impossível de falhar.

O valor probatório cresce por etapas. A ordem enviada prova o que o cliente declarou. 202 prova que o servidor permitiu avançar tratando a preparação como supérflua. 125 ou 150 prova que o estágio de dados foi iniciado ou preparado. Só a conclusão e a inspeção do arquivo sustentam a afirmação de que o conteúdo esperado chegou ao destino.

O RFC 3659 repete uma cautela parecida ao tratar permissões em listagens legíveis por máquina. Um indicador de escrita nunca garante que a operação apropriada funcionará; limitações do sistema, inclusive espaço disponível, ainda podem fazê-la falhar. A permissão é guia, não recibo. Embora seja outro recurso, a distinção ajuda a ler ALLO sem transformar possibilidade em resultado.

Uma função opcional ainda podia ser alcançada

O RFC 1123, de 1989, colocou o suporte servidor a ALLO na categoria opcional. Ao mesmo tempo, exigiu que o programa FTP do usuário oferecesse QUOTE, capaz de transmitir uma sequência arbitrária ao servidor e mostrar todas as respostas.

A discussão cita SITE e ALLO como exemplos de ordens específicas do sistema ou opcionais. Mesmo que a interface não as conhecesse como recursos próprios, o usuário teria uma passagem explícita. Isso evitava que o núcleo do cliente acumulasse todos os costumes locais e, ao mesmo tempo, não isolava uma capacidade do servidor.

O registro IANA de comandos e extensões FTP continua listando ALLO como comando básico “Allocate”, com referência ao RFC 959. O registro resolve identidade e referência da palavra. Não é evidência de que um servidor em produção implemente reserva, disponha de espaço ou tenha concluído determinado envio.

O log precisa mostrar o que aconteceu depois do verde

Registrar apenas “ALLO OK” apaga a semântica decisiva. Uma trilha auditável guarda a linha completa, os inteiros, TYPE, STRU, o código numérico e o texto da resposta. 200 e 202 pertencem à classe positiva, mas um pode refletir execução local e o outro declara a desnecessidade da operação.

Depois, a trilha liga o preparo ao STOR ou APPE: conexão aberta, bytes enviados e recebidos, interrupções, código final, arquivo criado, tamanho e hash. Para responder sobre capacidade, preserva também espaço livre, quota relevante, limites do diretório e atividade concorrente no instante correto.

Não se deve supor que bytes lógicos ocupam igual número de blocos. Estrutura de registro, representação de caracteres, arquivos esparsos, metadados e escrita temporária alteram o custo local. A declaração organiza a conversa; não substitui a contabilidade do sistema.

Nem mesmo uma conclusão FTP positiva promete, sozinha, retenção indefinida, replicação ou restauração. Quando essas propriedades importam, o operador relê e verifica o objeto e suas cópias. A disciplina não é desconfiar de todo protocolo, mas perguntar exatamente qual etapa produziu cada evidência.

Fontes