摘要

  • FTP 要求先用 RNFR 指定旧路径，再立即用 RNTO 提供新路径；前者的 350 是肯定中间答复，不是重命名完成。
  • RFC 3659 后来把来源对象的 f 权限、目标目录的 c 权限与可选 Unique 对象事实分开，使名字、能力与对象连续性不再混成一件事。
  • 标准规定了命令顺序和回复含义，却没有承诺原子性、持久性、覆盖规则、崩溃安全或当前服务器部署情况。

一个看起来像成功的停顿

客户端发出 RNFR old-name。服务器回答 350 Requested file action pending further information。如果审计系统只把第一位数字分成“失败”和“非失败”，记录里已经出现了一次成功操作。

可文件还没有得到新名字。RFC 959 把 3xx 定义为肯定中间答复：命令已被接受，请求的动作仍被搁置，等待客户端补充信息。对重命名而言，缺少的信息就是 RNTO 中的新路径。

更早的 RFC 765 已经规定同一结构：RNFR 指定将被重命名的文件，并且必须由 RNTO 立即跟随；后者为前一条命令中的文件指定新路径。造成重命名的是两条命令的组合，不是第一条命令或第一份肯定答复。

这段停顿很短，却是协议有意表达的状态。它告诉客户端可以继续，但没有让观察者宣称变更已经提交。

“立即跟随”是一条证据约束

FTP 把 RNFR/RNTO 归入顺序命令组。若序列中任何一步失败，规范要求从头重做。服务器保存的是足以理解下一条目标命令的会话上下文，而不是一张可永久续用的交易票据。

因此，RNTO 必须属于同一控制连接，并指向紧邻的 RNFR。缺少合适前序时，RNTO 可以得到 503 Bad sequence of commands。若日志分开保存两条命令、丢掉连接标识或没有严格顺序，它就无法证明目标路径与哪一个来源配对。

这也限制了我们能从 350 推导的结论。它不证明来源已被锁定，不证明目标名已被保留，也不保证后续授权一定通过。它只证明服务器在那一刻接受了待续的来源步骤。

一条可审计的重命名至少包含三种事实：客户端提出哪个来源；服务器是否接受来源进入中间状态；服务器对目标变更给出什么最终结果。把三者压成一个“成功”字段，便会制造一次尚未发生的重命名。

350 与 250 不是同一种肯定

RFC 959 对 2xx 的定义是肯定完成：请求的动作已经成功结束，可以开始新的请求。250 的具体含义正是请求的文件动作正常、已完成。350 则明确保留了“等待进一步信息”。

两者都不是错误，但它们处于不同阶段。350 是继续序列的许可；250 才是该次协议交换中的完成证据。回复码的第一位不是情绪评分，而是一张简化的状态机。

最终答复若在网络中丢失，客户端面对的不是确定失败，而是结果未知。此时应重新观察命名空间，再决定是否重试。把之前的 350 当作持久事务标识继续使用，没有标准依据；顺序组的恢复规则反而要求从起点重新建立上下文。

来源与目标属于不同的权限表面

原始协议已经暗示重命名要解析两个路径。RFC 3659 的 perm 事实进一步揭示了两侧的能力差异。

对象上的 f 表示当前 FTP 用户可以把它作为 RNFR 的对象。目录上的 c 表示可以在那里创建文件，因而对其中名字发出 RNTO 很可能成功。一个能力属于来源对象，另一个属于目标容器。

规范用的是“很可能”，而不是“保证”。列表中的能力事实可以帮助客户端规划操作，却不会预留目标名、冻结访问策略或消除并发变化。最终回复仍然不可替代。

这种拆分在现代控制面同样重要。拥有释放一个对象的权限，不等于能在任意目标空间建立名字。用模糊的“可编辑”覆盖这两侧，会把原本有限的授权扩张成跨边界能力。

名字改变时，怎样观察对象连续性

RFC 3659 还定义了可选的 Unique 事实。服务器若提供它，指向同一底层文件的路径应给出同一不透明值，不同文件应给出不同值；一致性至少要维持一个控制连接的寿命。

规范中的示例很有启发性：mlst.c 先带有一个 Unique 值；客户端收到 RNFR mlst.c 的 350，随后用 RNTO list.c 得到 250；之后列出的 list.c 仍带同一 Unique 值。路径变了，服务器在限定范围内提供的对象线索没有变。

边界同样重要。服务器不必支持任何特定 MLSx 事实，Unique 不是全球标识、内容哈希或永久 ID。这个示例也不能证明所有实现中的所有重命名都保持该值。它只展示了一种更精确的证据组合：回复证明协议动作，可选对象事实加强新旧名字指向同一底层对象的判断。

登记表不替文件系统作保证

RFC 1123 把 RNFR 和 RNTO 保留在 FTP 主机命令要求中。RFC 5797 后来又把两者列为基础强制命令，并给出登记分类。IANA FTP 命令与扩展登记表 延续了这些条目。

这些材料证明互操作词汇受到协调，不证明某台服务器当前开放命令，也不回答目标存在时是否覆盖、并发观察者能否看到中间状态、数据何时落盘、崩溃后怎样恢复或跨文件系统路径怎样处理。

协议历史留下的窄结论已经足够重要：客户端和服务器必须区分“来源步骤被接受”与“重命名已完成”。其下的存储语义仍需实现、策略和运行证据来说明。

文件曾经位于两个名字之间

这对老命令为现代多阶段操作留下了一种诚实语言。服务器可以先确认提案足够完整、允许调用者继续，却把“提交”保留给真正产生变更的阶段。

好的控制面会命名中间状态，限定它属于哪个会话或事务，说明什么使它失效，并区分来源权限、目标权限和对象身份。审计面板也应允许“已接受、待完成”存在，而不是急着把所有肯定答复涂成绿色。

FTP 的 350 不是含糊的成功，而是精确的非最终成功。文件进入了一个协议序列，并未因此进入新路径。那次重命名尚未发生，而回复码本来就这样说。

来源