Summary

  • STOU let an FTP client submit bytes without supplying the new file’s pathname. The server allocated a name unique within the current directory and had to return the actual pathname before the transfer.
  • RFC 1123 corrected a revealing RFC 959 error: a preliminary 125 or 150 FILE: reply names the file that will be written, while a later 226 or 250 says whether the file action completed. Allocation and outcome are separate evidence.
  • The design solved one namespace collision. It did not create a globally stable file identifier, durable custody, authorization, confidentiality, safe restart semantics or evidence of present deployment.

The reply that tried to occupy two moments

One sentence in the October 1985 File Transfer Protocol specification contains a small contradiction with large consequences. The new Store Unique command was to create a file under a name unique to the server’s current directory. The server, the sentence said, must include that generated name in a “250 Transfer Started” response.

But FTP’s reply vocabulary assigned 250 to a different moment: the requested file action was okay and completed. A transfer that was merely beginning belonged to 125, when a data connection was already open, or 150, when the server was about to open one. The same specification’s command table placed 125 or 150 before the transfer and 226 or 250 after it. “250 Transfer Started” was not merely imprecise prose. It tried to use a completion code as a preliminary receipt.

Four years later, the Internet Host Requirements repaired the sequence. A server receiving STOU had to disclose the actual pathname in one of two exact lines before transfer:

125 FILE: pppp

150 FILE: pppp

Here pppp was the pathname of the file that would be written. The future tense mattered. The reply established which name the server had allocated. It did not say that all bytes had arrived, that the file would remain available, or that a later reader could open it. Those belonged to later protocol states and to local storage policy.

The correction is a compact history of evidence design. A request, an allocation and a completed operation may occur inside one dialogue, but they are not interchangeable. The server could speak truthfully about the name before it possessed enough evidence to speak truthfully about the transfer.

A protocol that knew operations but not names

FTP inherited a difficult boundary from the computers it connected. The 1971 protocol described a file as data uniquely identified within a system by its pathname. It standardized operations across the network, yet it did not standardize the naming conventions of the remote file systems. A user had to follow the serving host’s conventions.

That was a substantial burden disguised as a string. A pathname might contain directory, device and file components meaningful only on the receiving system. The sender needed enough knowledge of that foreign namespace to identify the destination. Under an ordinary store request, an existing named file could be replaced; otherwise a new file could be created. Choosing a name therefore was not cosmetic. It could determine which local file was changed.

The early protocol also kept file protection where the relevant knowledge lived. A resident file system decided selective access. FTP carried identifiers and passwords, but it did not turn a remote pathname into a right to write. Name syntax, collision behavior and authorization belonged to related yet separate surfaces.

This arrangement worked when the client actually knew the desired remote file. It was less convincing for a receiving pool: a place where independent senders should be able to deposit work without learning the storage system’s private layout or overwriting one another.

The pool existed before the command

In 1973, RFC 505 examined an awkward form of file delivery. How could one person send a file to another host without knowing the recipient’s password? One answer was to reverse the direction: let the intended recipient pull the file using their own authority. That preserved access control, but it required the recipient to be present while the source was available.

The other answer borrowed a Multics practice. Unsolicited input could go to a pool directory rather than directly into the alleged recipient’s directory. The recipient would be informed and could later copy the file. The pool limited two dangers at once: an outsider should not consume another user’s directory allocation, and a deposit should not overwrite an existing personal file.

RFC 505 proposed a POOL id name command. The sender still offered a desired name, but the server would add whatever prefix or suffix was needed to make that name unique within the pool. The recipient notification would carry the suitably modified local pathname. The document also recognized a deeper portability problem: without an explicit recipient identifier, the server might have to infer one from a pathname, forcing the sender to know too much about internal structure.

The proposal did not establish a deployment history, and POOL did not simply become STOU. Its value is more precise. It exposed the problem that Store Unique later narrowed: the party receiving files controlled the collision domain, so it needed to allocate or adapt names inside that domain and report the result to parties outside it.

Why a new verb carried less authority

RFC 949 arrived in July 1985 with examples that now feel like physical metaphors for distributed systems: pool directories feeding printer daemons, fax daemons and even card-punch queues. Multiple senders could deposit work, but none should be required to choose a name that collided with work already waiting.

The proposal considered modifying STOR, adding a control argument, or treating a store without an argument as a special case. It instead chose a separate command. Reopening existing STOR handling seemed undesirable, while implementations were assumed to dispatch on command names in a way that made a new verb comparatively tractable. After rejecting several awkward abbreviations, the document settled on STOU.

The semantic change was deliberately small. STOU behaved like STOR, except that the resulting file would be created in the current directory under a name unique to that directory. The sender no longer provided the final pathname. The server had to tell the sender what the name became.

This was not the creation of broad server power. The server already controlled the remote namespace and file system. STOU made one existing control surface explicit and accountable: if the server alone could see which names were free, it would choose one and return evidence of its choice. RFC 949 expressly warned that the new command did not sidestep access control, authentication or accounting. The authority to allocate a free name did not authorize the caller to store arbitrary content.

The absence after STOU

RFC 959 incorporated STOU only three months later as one of seven new optional commands. Its formal syntax made the division visible:

STOR <pathname> <CRLF>

STOU <CRLF>

The missing pathname was the point. A client could have selected the current directory earlier in the session, but it did not name the new file inside that directory. That narrower request reduced a race: the client was not expected to inspect a directory, invent a seemingly unused name and hope that no other client chose it before the store began.

The guarantee was also narrower than the word “unique” can suggest. RFC 959 said unique to the current directory. It did not promise a name unique on every server, unique forever, unique across directories or unique to a particular sequence of bytes. It did not say the name could never later be reused. The scope was the namespace in which the server made the allocation.

The command remained optional. Its presence in a standard did not make support universal. Its absence from the argument list did not erase session context. Its successful preliminary reply did not erase the transfer state machine. Each of those limits prevents a convenience mechanism from becoming a larger claim than the protocol supplied.

A machine-readable exception inside human text

FTP replies were designed with two audiences. A three-digit number told a program what state to enter; the following text was usually for a person and could vary by server. That division made the original STOU wording especially fragile. If the pathname lived in unspecified prose, a client would have to recover a machine decision from text that the protocol otherwise allowed servers to phrase differently.

RFC 1123 solved that by fixing both the phase and the grammar. The actual pathname had to be in the preliminary 125 or 150 line, and FILE: supplied a stable marker. Client software could retain the remote string without guessing where the server’s commentary ended and the name began.

The ordering created a useful ledger of claims:

  1. The client requested STOU in a session with some current-directory and access state.
  2. The server returned a preliminary line naming the file it was about to write.
  3. The data connection carried some amount of data or failed.
  4. A final positive or negative reply described the outcome known to the server at that stage.
  5. Local policy determined later visibility, retention, pickup, rename or deletion.

Collapsing those entries loses information. If a client records only the final 250, it may know that a file action completed but lose the only protocol field that identifies the allocated pathname. If it records only 150 FILE:, it may know the planned name while remaining ignorant of whether the transfer succeeded. A narrow receipt is useful precisely because its jurisdiction is clear.

“Will be written” is not “is safely kept”

The pre-transfer name can be operationally valuable. A client can associate later events with the pathname the server selected. A queue operator can match an orphaned entry with a session record. A recipient can be told which remote name to claim. But every use depends on preserving the distinction between an allocation and custody.

A positive preliminary reply does not prove that the data connection opened successfully. It does not prove that the sender delivered the expected byte stream. It does not prove that a later completion reply arrived, or that an observer retained it. Even a final success reply remains a statement at the FTP and server boundary; it does not promise backup, immutable retention, continued permissions or future availability.

This is the practical meaning of the reply-code correction. The server did not wait until the final response to disclose the name because the name was already decided. It did not put completion into the preliminary response because completion was not yet knowable. The protocol preserved time as part of evidence.

Why restart could not assume the same stored file

The boundary became visible again when FTP restart for stream mode was specified more fully. A restart asks two sides to continue an earlier transfer at a known position. For RETR or STOR, that requires an existing source or destination file that both sides can identify as the prior transfer target well enough to resume.

RFC 3659 allowed that a server might accept other commands after REST, but advised against combining restart with STOU. It called the result undefined: storing the remainder of a file into a newly unique filename was rarely useful.

The problem is not that a byte offset and a generated name use different syntaxes. It is that they answer different continuity questions. A restart marker refers back to partial state. STOU asks the server to allocate a new pathname. A fresh name supplies no evidence that it denotes the same stored file that received the earlier prefix. If a server chooses to support the combination, its local behavior needs information that the general command pair does not establish.

This is materially different from FTP’s restart history itself. The important point here is the collision between two contracts: “allocate something new” and “continue this particular old thing.” Composition fails when neither mechanism carries the missing continuity relation.

The second meaning of unique

RFC 3659 later used the word in another FTP mechanism. A machine listing could contain a Unique= fact: an opaque token intended to be equal when two different pathnames referred to the same stored file. The token should differ for distinct stored files and remain consistent for at least the lifetime of the control connection.

That evidence runs in the opposite direction from STOU. Store Unique asks for a pathname that does not collide within the current directory. The listing fact helps a client recognize that two pathnames may nevertheless designate one stored file, as with hard links. One concerns name allocation; the other concerns same-file comparison.

The RFC carefully bounded the latter. The token was opaque and case-sensitive. Equal values permitted one conclusion: the names referred to the same stored file. The server should not expose a filesystem identifier whose disclosure could bypass protection mechanisms. Even an identifier designed for comparison had to remain weaker than an access capability.

Putting the two forms of uniqueness beside each other prevents a common modeling error. A unique pathname need not denote a permanently distinct stored file. One stored file can have more than one pathname. Neither fact proves ownership, content integrity or durability.

Collision control was never a security layer

RFC 949 was explicit that STOU did not displace authentication, accounting or access control. Later FTP security guidance makes the remaining gap impossible to miss. Standard FTP sent passwords, control information and data without encryption. Its separate data connection created opportunities for connection theft or forged data insertion unless stronger protections and peer checks were used.

A server can allocate two different names while accepting data from the wrong peer. It can prevent one pathname collision while exposing the control dialogue. It can return an exact remote name while local permissions later make the file unreadable. All of those statements can be true together because naming and security operate on different evidence.

The narrowness is a strength when kept visible. STOU did not need to become a permanent file-identification system to solve its collision problem. The mistake would be to let a correct local allocation serve as evidence for security claims it never attempted to establish.

What the registry preserves—and what it cannot show

RFC 5797 and the current IANA FTP Commands and Extensions registry still carry STOU as an optional base command, referring to RFC 959 and RFC 1123. That is useful historical and namespace evidence. It prevents the same command label from being assigned a conflicting meaning and points an implementer to the documents that define the command and its correction.

The registry specification warns against reading more into such a row. Its primary purpose is to avoid conflicting uses of command and extension names. Registration is not a declaration that a feature is approved, widely implemented, safe in a particular environment or presently used. The lowercase base entry is a placeholder for registry organization, not a FEAT advertisement that servers must return.

Protocol history therefore has two distinct sources of truth. The registry can tell us what STOU is assigned to mean. Only observations of particular implementations and sessions could tell us whether it is supported or used there. This article has no deployment census and makes no such claim.

A small command with a durable institutional lesson

Store Unique did not standardize the world’s pathnames. It took the opposite approach. The remote system retained its naming conventions, its current directory and its access policy. The common protocol added only enough structure for an external client to request a collision-free allocation and receive the resulting remote name.

That is a thin contract. It locates the decision with the system that can actually see the collision domain. It requires that system to return evidence usable by an automated peer. It preserves a separate completion phase. It refuses, by omission and by explicit warning, to convert naming into security or permanent custody.

The lesson is not that centralized allocation is always desirable. It is that control and proof should be co-located at the smallest relevant boundary. A client should not pretend to know which remote name is free. A server should not pretend that choosing one proves the transfer complete. A registry should not pretend that recording a command proves deployment. Each actor contributes one bounded fact and remains accountable for what only it can know.

Sources