Summary

  • FTP's ALLO command let a client declare the logical storage expected for a following STOR or APPE, with an additional size available for record- or page-structured files.
  • A server that did not need advance allocation was supposed to treat the command as a no-operation. Its 202 reply was positive because the client could continue, not because bytes had been reserved.
  • Storage evidence belonged to the later data transfer, final reply, quota state and resulting object. Collapsing those stages into one success flag concealed the protocol's most useful distinction.

The file had a size before it had a destination

A sender often knows a file's length before opening the data connection. Telling the receiver early seems like an obvious efficiency: reserve the required space, reject the job if it will not fit, and avoid spending network time on a doomed transfer. That story assumes, however, that every host exposes the same kind of reservation.

The early Internet connected machines whose storage systems did not share that assumption. One host might need to allocate space before a file could be written. Another might extend a file as data arrived, with no separate operation corresponding to “reserve this many bytes.” A protocol that demanded the first behavior everywhere would turn a local storage design into a network admission rule.

RFC 354, published in 1972, placed both models inside the definition of ALLOCATE (ALLO). Some servers might require the command to reserve sufficient storage for the new file. Its decimal argument represented bytes using the selected byte size, and a STORE or APPEND command was to follow.

The same definition instructed servers that did not require a maximum size to be declared beforehand to treat ALLO as a no-operation. This was not an omission left for implementers to repair. It was an interoperability choice. The client could express a planning need without acquiring authority over the server's storage model.

RFC 765, published in 1980, made the declaration more precise. The first integer represented the file's storage in logical bytes. A record- or page-structured file could also carry a maximum record or page size, introduced by space, R, space. A server interested only in that second quantity was to accept a dummy first value and ignore it.

The grammar exposed the limits of the number. A logical byte count was not necessarily a count of filesystem blocks, a quota debit, a compressed wire length or a durable physical allocation. It was a description in the active FTP representation, offered to a server that might translate it into a local resource operation.

A positive answer to an action that did not happen

RFC 959 retained the command in 1985. Its syntax required one decimal integer and allowed R plus a second. ALLO was to be followed by STOR or APPE, and servers that did not require a prior maximum declaration should treat it as NOOP.

The reply rules supplied the sharper boundary. A command such as TYPE or ALLO whose successful execution offered the user process no new information would receive 200. If a particular server did not implement ALLO because allocation had no relevance to that computer system, a positive completion was still desired. A simple user process then knew it could proceed with its intended sequence. The assigned reply was 202, with “No storage allocation necessary” as the example text.

The generic description of 202 is “Command not implemented, superfluous at this site.” Both halves matter. The server disclosed that the requested operation was not implemented. It also disclosed why that absence did not block the user's course. The positive property belonged to progress through the protocol, not to a physical reservation.

RFC 959 distinguished that case from 502, used when a non-site-specific requested action was unimplemented, and 504, used for an unimplemented parameter of an available command. The reply taxonomy did not simply paint every unsupported action green. It asked whether the omitted action mattered on that system.

A 200 should not be inflated into a universal durable receipt either. A server may have performed a real reservation, but the code alone says nothing about physical block count, holding period, quota interactions, concurrent writers or persistence. The specification uses it precisely where successful execution brings the client no new information. Stronger semantics require implementation and operational evidence.

Capacity waited behind the next command

ALLO did not carry file content. The following STOR asked the server to accept data over the data connection and store it under a pathname. If the file already existed, the transferred data would replace it; if it did not, the server would create it. The planning claim now met the connection, permissions, pathname and storage system.

The reply sequence separated beginning from outcome. 125 said the data connection was already open and transfer was starting. 150 said the file status was satisfactory and a data connection was about to be opened. Both were preliminary replies. A positive completion could later arrive as 226 or 250; connection, local-processing, pathname, authorization and storage failures retained their own endings.

Two replies make the evidentiary boundary unmistakable. 452 means that the requested action was not taken because the system had insufficient storage space. 552 means that the requested file action was aborted because a storage allocation, such as the current directory's or dataset's, had been exceeded. A session could therefore receive a positive 202 for ALLO and fail at STOR without contradicting the protocol. Advance reservation was unnecessary; later capacity was not guaranteed.

The evidence grew in stages. Before ALLO, the client had its own estimate. After 202, it had the server's permission to continue without that preparatory action. After 125 or 150, it knew that the data phase was open or approaching. Only an appropriate final reply and inspection of the resulting file supported the stronger claim that the expected content had been stored.

RFC 3659 repeated a related caution when describing machine-readable file permissions. A write permission indicator could never imply that the appropriate command was guaranteed to work. System-specific limits, including available storage space, might still make the operation fail. The permission was a guide. That passage did not redefine ALLO, but it preserved the same distinction between apparent eligibility and executed result.

Optional support did not make the command unreachable

RFC 1123, the 1989 host requirements, placed server support for ALLO in the optional category. At the same time, it required a user FTP program to implement QUOTE, a facility that passed an arbitrary character string to the server and displayed all resulting replies.

The discussion named SITE and ALLO as examples. A user could reach a system-specific or optional facility even when the client had no dedicated understanding of it. That arrangement limited the client core without sealing off server variation. It also preserved the raw reply, which mattered because 202 carried more useful meaning than a generic success lamp.

The IANA FTP Commands and Extensions registry still lists ALLO as the base command “Allocate” and cites RFC 959. Registration establishes vocabulary and reference. It does not inventory deployment, attest to a server's allocation behavior, measure free capacity or prove that a particular transfer reached storage.

An audit trail has to outlive the first positive code

A log entry reading only “ALLO successful” destroys the designed distinction. A useful trace preserves the exact command, both integers where present, the active TYPE and STRU, the numeric reply and the complete reply text. 200 and 202 are both positive, but they describe different local decisions.

The trace must then correlate the preparation with the following STOR or APPE. Did the data connection open? How many bytes crossed it? Was the transfer interrupted? What final reply arrived? Did the target object exist with the expected size and checksum? A capacity claim also needs free-space, account-quota, directory-limit and competing-activity evidence from the relevant time.

The conversion from logical size to local cost should remain visible. Record structure, character representation, sparse allocation, metadata and temporary-file strategy can all change the resources consumed. The protocol declaration coordinates planning; it does not replace storage accounting.

Even a final positive FTP reply does not, by itself, prove indefinite retention, replication or future recoverability. Where those properties matter, the object must be read back, checked and, if necessary, recovered from its intended copy. The point is not to distrust protocol replies. It is to keep every conclusion within the scope of the stage that produced it.

Sources