摘要

  • ALLO 让 FTP 客户端在 STOR 或 APPE 之前申报逻辑字节数；记录或分页结构还可附带最大记录、页长。
  • 不需要事先分配空间的服务器应把命令当作空操作，并可用肯定完成码 202 告诉简单客户端继续；该答复不是空间保留凭据。
  • 存储是否成功，要沿着数据连接、初步与最终回复、配额状态和最终文件逐层验证，不能由一个绿色控制码代替。

先到达的是数字，不是文件

早期网络把差异很大的主机连到一起。发送方或许知道文件有多少字节，却不知道对端怎样管理磁盘。有的系统必须先划出连续或受配额约束的空间，才能接收新文件；有的系统在写入过程中逐块增长；还有的系统根本没有一个可以对应“预留”的独立动作。

如果协议只允许第一种实现，其他系统就会因为做不到无必要的准备动作而被排除。如果所有服务器都用同一句“已经预留”敷衍客户端，又会把兼容性建立在虚构保证上。FTP 的做法更细：允许客户端提出规划信息，也允许服务器明确认为它多余。

1972 年的 RFC 354 已经定义 ALLOCATE (ALLO)。某些服务器可能需要它，以便为将要传来的新文件留足存储。参数是十进制整数，按当时选定的字节大小计数；之后应跟 STORE 或 APPEND。但对于不要求预先声明文件上限的服务器，规范要求把 ALLO 视作无操作。

这条分支说明，申报值首先是一条请求。客户端控制数字，服务器决定这个数字能否、是否需要映射为本地资源。规范没有把所有主机的文件系统抹平成一种模型，而是给会话保留共同进度。

1980 年的 RFC 765 把表达扩展得更精确。第一个整数表示文件所需的逻辑字节。若文件采用记录结构或分页结构，还可能需要最大记录或页的逻辑大小，于是命令可带第二个整数，中间用空格、R、空格分隔。若服务器只关心后一个值，它应接受一个占位的第一整数并忽略它。

因此，ALLO 的数字不能直接当成物理块、传输线上压缩后的八位组、配额扣减或最终落盘大小。它属于 FTP 表示层。服务器仍须把逻辑描述翻译成本机操作，而这一步可能根本不存在。

202 的肯定，肯定的是“可以继续”

1985 年的 RFC 959 保留了这一命令。语法是一个十进制整数，后面可选 R 和另一个整数；ALLO 之后必须是 STOR 或 APPE。不要求预报最大文件的服务器仍应把它作为 NOOP 处理。

关键藏在回复码的用途里。像 TYPE 或 ALLO 这样执行成功、却不向用户进程提供新信息的命令，可以收到 200。若某台服务器没有实现 ALLO，原因是这项操作对该计算机系统没有意义，规范仍希望给出肯定完成回复，让简单客户端知道可以继续原计划。对应的代码是 202，示例文字是“No storage allocation necessary”。

202 的通用说明是“命令未实现，在本站属多余”。它不是语法错误，也不是拒绝继续。它同时陈述了两个事实：请求的动作没有实现；缺少这个动作不妨碍后续工作。肯定状态属于流程，不属于容量。

如果一项并非站点特有的动作未实现，答复应是 502；若命令存在但某参数不支持，可用 504。因此 202 并非模糊地把所有失败涂绿，而是表达本地系统对动作必要性的判断。

200 也不能自动扩大成持久承诺。它可能对应真实的本地预分配，但规范只说成功执行且没有更多信息。仅看这个三位数，无法知道服务器留了多少物理空间、保留多久、是否受目录配额约束、并发写入会不会消耗同一资源。若这些问题重要，就必须寻找实现与运行证据。

真正要写入时，容量问题才现身

ALLO 不承载文件内容。后续的 STOR 才要求服务器从数据连接接收数据，并以指定路径存储。若文件存在，规范要求用传入数据替换；若不存在，则创建。这一步才把控制会话里的计划放到权限、连接、文件系统和容量面前。

回复顺序也区分阶段。125 表示数据连接已经打开，传输开始；150 表示文件状态允许操作，即将打开数据连接。二者都是初步回复，只说明工作进入下一阶段。之后的 226 或 250 可以表示积极完成；连接中断、本地处理失败、路径问题和存储限制另有终局代码。

其中，452 表示由于系统存储空间不足，请求的动作没有执行。552 表示文件动作被中止，因为超过当前目录或数据集的存储分配。一个会话先得到 202、后来得到 452 或 552，在语义上完全一致：服务器此前只说无需预先分配，并没有说后续写入不可能耗尽空间。

这一顺序建立了证据等级。ALLO 之前，客户端只有自身估算。收到 202 后，它有继续的协议许可。收到 125 或 150 后，它知道数据阶段开始或将开始。只有最终回复以及对结果文件的检查，才能支撑“内容已按预期存下”的更强判断。

RFC 3659 在机器可读目录的权限说明中再次划出类似边界。即便某个文件对象标有可写权限，也绝不保证相应命令一定成功；可用空间等系统特有限制仍可能使操作失败。权限只是指引。它讨论的不是 ALLO 回复，但同样反对把资格信号误读成执行结果。

可选命令并没有被关在实现之外

1989 年的 RFC 1123 在 FTP 要求汇总中，把服务器支持 ALLO 放在可选一栏。与此同时，它要求用户端 FTP 程序提供 QUOTE：把任意字符串传给服务器，并把全部回复显示给用户。

规范的讨论直接举出 SITE 和 ALLO。即便客户端没有把某项站点特有或可选能力做成专门按钮，用户仍可显式访问。这样，客户端核心不必知道所有主机传统，服务器也不必放弃本地能力，协议还为人保留一条可观察的通道。

IANA 的 FTP 命令与扩展登记表 至今把 ALLO 列为基础命令“Allocate”，引用 RFC 959。登记表能回答这个四字母词属于哪项标准化语汇，却不能回答某台在线服务器是否实现、是否预留、是否有余量，更不能证明某次文件传输完成。

一份可审计记录应保留整条链

运维日志若只写“ALLO 成功”，会抹掉最重要的差别。应保存命令原文、一个或两个整数、当时的 TYPE 与 STRU、数值回复码和完整回复文字。200 与 202 都是肯定类，但前者可表示本地执行，后者明确表示动作在本站多余。

随后必须把它关联到紧接的 STOR 或 APPE：数据连接是否建立，发送和接收了多少字节，是否发生中断，最终回复是什么，目标文件是否存在，大小与校验值是否符合预期。若要判断容量，还要保留相关时点的可用空间、账户配额、目录限制和并发活动。

逻辑字节声明与物理占用之间的换算也不能隐藏。记录结构、字符表示、稀疏分配、文件系统元数据乃至临时写入策略都可能改变资源成本。协议提供协调语言，但不会替操作者完成这种核算。

即使 FTP 返回最终肯定码，也不自动证明长期保存、复制或未来可恢复。高价值场景需要再次读取、校验，必要时验证备份副本。正确做法不是怀疑所有回复，而是把每项结论约束在产生它的阶段。

来源