Summary

  • FTP's original restart marker lived inside block or compressed transfer framing. A 110 MARK ssss = rrrr reply paired a sender-owned position with a receiver-owned position made durable at stable storage.
  • The pair could carry local conversion state, not merely a count. RFC 1123's example requires a receiver to remember that it has consumed a carriage return while translating network CRLF into one local newline.
  • RFC 3659 later defined REST STREAM as an octet count for the immediately following transfer, while warning that restart is unsafe if the source or partial destination has changed. An offset is a continuation instruction, not a file identity or integrity proof.

The reply arrived without stopping the file

FTP has always divided conversation from cargo. Commands and numbered replies cross a control connection; file contents move on a separate data connection. That split made a peculiar event possible. While data continued to flow, the receiving side could send a 110 reply over the control channel and report a place from which both ends might recover later.

The corrected form in RFC 1123 is deliberately symmetrical:

110 MARK ssss = rrrr

The string ssss had appeared in the data stream and encoded a position in the sender's file system. The string rrrr encoded the corresponding position in the receiver's file system. Each marker was generated and would later be interpreted by the same system. The equality sign did not say that the two strings were numerically equal. It said that they met at one recovery boundary.

Nor was the reply an instruction to pause. A sender emitting restart markers was forbidden to assume that 110 replies would return synchronously. It had to keep sending instead of waiting for each checkpoint to come back. Recovery evidence was allowed to lag behind useful work.

This is the first distinction modern interfaces hide. A progress counter says how much motion has been observed. A restart checkpoint says which earlier state both sides can reconstruct after failure. The two may coincide in a simple byte-preserving transfer. FTP was designed for systems in which they often did not.

The marker needed a framed mode

RFC 959 defined three transfer modes. Stream mode sent an unstructured sequence and normally used closing the data connection to signal end of file. The specification called that ending inherently unreliable: close alone could not reveal whether the file ended normally or the connection died early. Block and compressed modes carried their own FTP framing, including explicit end conditions.

In block mode, a three-octet header preceded each block. The high octet held descriptor bits and the lower two held a byte count. Descriptor value 16 meant that the block carried a restart marker. The marker was a printable character string embedded in the data stream, without spaces. It was not user data, and it was not inferred from TCP sequence numbers. FTP deliberately placed a recovery landmark inside the representation that both data-transfer processes understood.

That choice connected restart to mode. RFC 1123 later stated the consequence plainly: the original mechanism required block or compressed mode because those modes could insert markers into the data stream. The frequency could be low. A checkpoint did not need to accompany every block to be useful.

The machinery also explains why a raw network capture was insufficient recovery state. A transfer process needed to know where the sender could recreate its outgoing representation and where the receiver could recreate its stored representation. Packet delivery supplied neither local fact by itself.

Stability came before the receiver minted its marker

On receiving a marker, RFC 1123 said the FTP implementation should force all prior data to stable storage before encoding rrrr. That order gave the reply its narrow authority. The receiver did not merely say, “these bytes crossed my socket.” It identified a position after which the preceding portion could survive the interruption model the implementation claimed to handle.

Stable did not mean globally permanent. The RFC did not define a storage medium, replication policy or disaster-recovery promise. It required the local process to make earlier data durable enough that its own restart token remained truthful. The marker belonged to the system that knew what “reposition here” meant.

The user FTP was expected to preserve the pair. RFC 1123 proposed a restart control file: create it empty when the transfer starts, append marker pairs as they arrive and delete it when the transfer completes successfully. That small sidecar was a recovery ledger. If the client crashed, the latest complete pair—not the largest display counter—was the safe candidate for another attempt.

Deletion mattered as much as creation. A completed transfer should not leave an apparently valid checkpoint available for an unrelated future file. Lifecycle was part of meaning: create at start, append only committed pairs, consume for the same interrupted transfer, remove at success.

A file position could include half a newline

Why were two opaque strings necessary? Because FTP could transform data between its network representation and each system's storage representation. A location in the wire stream did not always map to the same integer location on disk.

RFC 1123 offers an exact example. In an ASCII transfer, a receiver might turn the network sequence CRLF into one local LF. If a restart marker fell between CR and LF, the receiver had already seen and discarded CR but had not yet completed the newline transformation. Its rrrr value therefore needed to encode not only a file position but the state “CR has been seen.” Restarting from an integer disk offset without that state could add, lose or duplicate a character.

This was not ornamental heterogeneity. RFC 959 describes machines with different character codes, word sizes, local byte sizes and storage conventions. FTP's representation type, file structure and transfer mode were separate parameters because “the same file” had to cross unlike systems without pretending their internal layouts were identical.

A marker could therefore be opaque and still precise. Its portability was intentionally limited: only the system that generated the token had to interpret it. The protocol coordinated correspondence, not a universal storage coordinate system.

Direction changed who held which token

RFC 1123 works through three cases. In a user-to-server transfer, the user side inserts ssss; the server commits prior data, generates rrrr and returns the pair. To resume, the user repositions itself using its own ssss and sends REST rrrr to the server.

For server-to-user retrieval, the server inserts the stream marker. The client commits its local copy and records the corresponding local state. Later the client restores its own position and returns the server's marker through REST.

The third-party case is more revealing. FTP permitted one user process to control a transfer between two servers. The user held a checkpoint pair belonging to machines that might never share a file-system model. To restart, it sent the sender only the sender's token and the receiver only the receiver's token.

The client was a custodian of correspondence, not the author of either coordinate. That division reduced what a coordinator had to understand. It also imposed a discipline: marker pairs could not be mixed across transfers, reordered casually or interpreted by the wrong endpoint.

REST saved state; it did not perform the transfer

The REST command established a parameter for the next service command. A successful 350 reply meant the server had saved the marker and expected a transfer command. It did not mean that any file bytes had moved, that the partial object was valid or that completion would succeed.

RFC 959's state model pairs REST with a following RETR, STOR or APPE. RFC 1123 adds distinct error meanings. A 554 can say that the requested restart position cannot be applied. A 555 can say that the current type or structure does not match the existing file. Position and representation are separate conditions; one successful check cannot silently satisfy the other.

This two-command construction also creates stale state. If a client sets a restart marker and then fails to issue the intended transfer, the next operation can inherit an instruction whose purpose has disappeared. Later work would make the adjacency rule much more explicit.

STREAM mode narrowed the checkpoint to arithmetic

By the time RFC 3659 documented FTP extensions, clients and servers commonly wanted restart in the ordinary STREAM mode. That mode did not carry embedded FTP restart markers. The extension therefore chose a simpler coordinate: decimal octets.

In STREAM mode, REST 802816 tells the server not to send the first 802,816 octets of the immediately following transfer. The RFC's example sets image type, verifies that the server file has not changed, receives 350, then issues RETR. REST 0 removes the restart effect and requests the whole file.

The simplification was powerful because image-mode octets provide a common coordinate. It was also deliberately narrower than the paired-marker model. The numeric form did not encode a receiver's half-finished character conversion. It did not identify the source version. It did not say that the client still possessed exactly the prefix it claimed.

RFC 3659 thus made sequence part of correctness. REST must be the last command before the transfer it modifies. If the client cannot successfully send that transfer command, it should issue REST again before trying later. If the next transfer should begin from the start, it should explicitly send REST 0.

Syntax and feasibility can also fail at different times. A nonnumeric STREAM marker can be rejected immediately. A syntactically valid but out-of-range marker may be rejected only when the following transfer command supplies the file and operation context. Parsing a coordinate is not proof that the coordinate applies.

Resuming a store had a sharper edge

Restarting a retrieval leaves assembly authority with the client. It can place the returned suffix beside the prefix it already holds, re-fetch overlap or discard the result. Restarting a store asks the server to write incoming octets into an existing partial object. That gives a stale or mistaken offset more destructive power.

RFC 3659 limits the intended use to completing a previously failed transfer. For STOR, behavior is undefined if the restart marker is not at the end of the data already stored by the server. It is also undefined if the continuation supplies too little data to extend the destination at least to its earlier size. APPE, if a server permits it after REST, must act like STOR at the chosen position rather than append blindly.

These rules prevent the restart command from becoming a general sparse-file editing interface. They do not make continuation transactional. A failed second attempt can still leave another partial file. The operator must decide how partial destinations are named, protected, verified and removed.

The offset still needed evidence about the object

A perfectly parsed offset can point into the wrong version. RFC 3659 therefore recommends checking modification information before restart. For RETR, the client should obtain the server file's modification time before the first transfer and compare it again before continuing. For STOR, it can compare the partial destination with the source it is about to resume. MLST facts can give a stronger indication that the object has changed.

The warning is careful. Clients and servers need not share synchronized clocks, and time comparisons must allow for skew. A modification value can change for reasons other than different final content; content can change and later return. The evidence is an invalidation signal, not a cryptographic identity.

Size is also contextual. RFC 3659 defines a transfer size suitable for REST under the current type. It is not necessarily a universal on-disk size. A matching size cannot prove matching bytes, and a correct prefix plus suffix still needs whole-file verification if integrity matters.

The protocol therefore divides resumption into at least four claims: the feature is supported, the marker grammar is understood, the source and partial destination still belong to the same transfer, and the reconstructed result is correct. REST STREAM answers only the first two directly.

Feature advertisement named a capability, not a promise

A server that supports the RFC 3659 STREAM behavior advertises REST STREAM through FEAT. The exact token lets a client distinguish the numeric STREAM extension from restart support available only in block or compressed mode.

The current IANA FTP Commands and Extensions registry preserves the distinction. It lists base REST with RFC 959 and RFC 1123, and an amended REST+ entry for STREAM mode with RFC 3659 and the FEAT code REST.

That registry records a standardized command family. FEAT reports an implementation capability. Neither identifies a particular partial file, authorizes overwriting it, proves that the remote version is unchanged or measures how widely the mechanism is deployed today.

Recovery succeeded by keeping meanings local

FTP's two restart designs are not a simple story in which an awkward token was replaced by a sensible number. Each is sensible inside a different representation boundary.

The original scheme could survive conversions because the sender and receiver each described their own state. It required framed transfer modes, in-stream markers, asynchronous control replies and a persisted pair ledger. The later STREAM scheme fit the dominant octet stream and common image transfer. It removed embedded markers and made resumption easy to express, but transferred more responsibility to the client to prove that its offset still referred to the intended file.

In both cases, the checkpoint had less authority than the completed object. It told endpoints where they might continue. It did not authenticate who supplied the file, certify its meaning or replace verification after assembly.

Sources and evidence limits

The closed sources establish FTP's specified restart mechanisms, host requirements, later STREAM extension and command registry. They do not measure current product support, present deployment, transfer success rates or the integrity behavior of a particular server. The article therefore does not treat an IANA entry or FEAT token as evidence that a real continuation is safe.