Summary

  • FTP split rename into RNFR and RNTO; a 350 reply accepted the source into a pending sequence but did not say that any name had changed.
  • The immediately following destination command and its final reply carried the mutation outcome, while later MLSx facts separated source permission, destination creation permission and optional object continuity evidence.
  • The standards define command state and evidence boundaries, not atomicity, durability, overwrite policy, crash safety or present-day deployment.

A positive answer for an unfinished action

A client sends RNFR old-name. The server replies 350 Requested file action pending further information. The first digit is positive. An operator scanning for success may mark the rename done.

Nothing has been renamed yet.

RFC 959 defines a 3xx reply as positive intermediate: the command has been accepted, but the requested action is held in abeyance until the client supplies more information. In this case that information is a new pathname in RNTO. The protocol makes the waiting state visible instead of compressing intent and mutation into one cheerful result.

The earlier RFC 765 already carried the same structure. RNFR specifies the file to be renamed and must be immediately followed by RNTO; RNTO names the destination for the file in the immediately preceding command. Together, not separately, they cause the rename.

The server held context, not a completed rename

FTP describes RNFR and RNTO as a sequential command group. Replies show whether the preceding step reached a valid intermediate state. If any point fails, the specification says the entire sequence must be repeated from the beginning.

That recovery rule tells us what the server is holding. It has accepted enough source context to interpret the next destination command in the same control session. It has not issued a portable transaction handle, promised a lock, reserved the target name or certified that the source will remain unchanged.

The word “immediately” matters. RNTO refers to the file named by the immediately preceding RNFR. An RNTO without the required predecessor can receive 503 Bad sequence of commands. A log that separates the two commands by connection, omits order or records only their text cannot reconstruct the standard's state machine.

There are therefore at least three distinct facts. The client intended to rename a source. The server accepted a pending source step. The server later completed—or refused—the destination step. Only the last can support a protocol-level claim that the rename succeeded.

Why 350 and 250 cannot share one success bucket

RFC 959 says a 2xx reply is positive completion: the requested action has successfully completed and a new request may begin. It defines 250 as the requested file action being okay and completed. By contrast, 350 explicitly says the action is pending further information.

Many operational systems flatten both into “success” because neither begins with 4 or 5. That loses the strongest information in the reply grammar. The first digit does not merely grade happiness; it describes a state transition.

For RNFR, 350 is permission to continue the sequence. For RNTO, 250 is the completion evidence. If the final reply is lost, the client has an ambiguous outcome and should reconcile the namespace before deciding whether to repeat anything. Replaying from a remembered 350 is not continuing a durable transaction token; the protocol's own failure rule points back to the beginning.

Source authority and destination authority were different

The original command pair implies two path decisions, but RFC 3659 later made the separation more legible through the perm fact.

Permission indicator f on an object says that it may be the object of RNFR. Permission c on a directory says files may be created there and that RNTO is likely to succeed for names in that directory. The source object and destination container therefore expose different predicted capabilities.

“Likely to succeed” is deliberately weaker than a promise. A listing can describe what the current FTP user appears allowed to do at observation time. It does not reserve a destination, freeze policy, eliminate races or replace the final command reply.

This matters beyond FTP. A principal may be allowed to release or rename one object without being allowed to create a name in every destination. Systems that collapse those checks into a generic “can edit” flag make delegation broader than the underlying operation.

A name could change while bounded object evidence remained

RFC 3659 also defined the optional Unique fact. When a server supplies it, pathnames referring to the same underlying file should carry the same opaque token; distinct files should carry different tokens. The mapping should remain consistent for at least the lifetime of the control connection.

Its worked example is unusually useful. A listing shows mlst.c with one Unique value. The client receives 350 for RNFR mlst.c, sends RNTO list.c, and receives 250. A later listing shows list.c with the same Unique value. The pathname changed while the server's bounded object token remained.

The evidence boundary is strict. Servers are not required to support any particular MLSx fact. A Unique token is not a global identifier, content hash or permanent name. The example does not prove that every implementation preserves such a token after every rename. It demonstrates a vocabulary capable of separating the name transition from the underlying object comparison.

That is a stronger audit model than comparing paths. Before the operation, evidence can bind the source path to an object token. After a confirmed completion, it can bind the destination path to the same token. The rename reply proves the protocol action; the optional token strengthens the object-continuity claim. Neither substitutes for the other.

Mandatory vocabulary is not a filesystem guarantee

RFC 1123 retained RNFR and RNTO in the FTP host command requirements. RFC 5797 later listed both among mandatory base commands and assigned them registry classes. The IANA FTP Commands and Extensions registry preserves those entries.

Those records coordinate interoperable protocol vocabulary. They do not specify whether a particular rename is atomic to concurrent readers, whether a destination may be overwritten, whether old and new paths cross a filesystem boundary, when storage becomes durable, or how a server behaves after a crash. Nor do they prove that any particular public server permits the commands today.

The narrow claim is enough. FTP required the client and server to distinguish a pending source selection from a completed rename. Everything below that command boundary remained subject to implementation and policy evidence.

The file between two names

The old pair survives as a model for control planes. A multi-step mutation often begins with a server saying that the proposal is valid enough to continue. That answer can be useful without being a commit.

Good systems name the intermediate state, bind it to one session or transaction, state what invalidates it, and reserve completion language for completion evidence. They also distinguish authority over the source from authority over the destination, and the underlying file from its current display name.

FTP's 350 was not a weak success. It was a precise non-final success. The file had entered a protocol sequence, not a new pathname. The rename had not happened yet—and the reply code said so.

Sources