Summary

  • BBN 在 1980 年的 RFC 775 中给 FTP 增加四条实验性目录命令，让远程维护程序能建目录、删目录、查看位置、返回上级。
  • 关键不是“会建文件夹”，而是服务器建完后返回自己认可的完整路径；在 TOPS-20 上，创建时输入的短名字未必能用来进入新目录。

先建，再找，找不到。这套流程听上去像办公室笑话，RFC 775 却把它当作严肃的协议问题。BBN 当时为 ARPA 的远程站点维护项目照看几台运行 UNIX 的 DEC PDP-11。UNIX 的目录是一棵树，维护软件若能像处理文件那样处理目录，复制整棵树就顺手得多。可网络另一端未必也是 UNIX。TOPS-20、Multics 都有树状目录，写路径的方法却各有脾气。

BBN 的工程师给 FTP 服务器添了四个动作：XMKD 建目录，XRMD 删目录，XPWD 报告当前目录，XCUP 回到上一级。最后一个尤其像在提醒程序员：别把本机的“上一级怎么写”当成宇宙常数。RFC 把它作为 XCWD 改变工作目录命令的一个特例，使搬运目录树的程序可以请求“回上级”，无需掌握每种机器的父目录符号。

真正的陷阱在创建之后。设想客户端连接到 TOPS-20 的 <DFRANKLIN>，发出 XMKD MYDIR。目录创建成功，完整名字却是 <DFRANKLIN.MYDIR>。紧接着发 XCWD MYDIR 可能失败。输入的 MYDIR 是让服务器做事的参数，并不保证是下一步可反复使用的地址。程序如果擅自拼路径，辛苦建好的目录就在眼前，却像锁在隔壁房间。

所以 RFC 775 规定，成功创建后服务器应在回执里给出加引号的完整名字。它列出 257 "/usr/dm/child" directory created 这样的例子；换到 TOPS-20，就返回那台机器认可的尖括号与点号组合。文件夹名里若本来有双引号，回执里把引号写两次。这个小小的转义规则，保证客户端能把名字读对，而不是在第一个奇怪字符处把路径截断。

路径回执实际上分清了谁有资格给目录起“正式名”。客户端知道自己想要一个孩子目录；服务器知道自己的文件系统最终创建了什么。跨系统复制目录树时，程序先记住返回的完整路径，再进入它、放文件、返回上级。把 UNIX 的斜杠习惯硬塞给 TOPS-20，网络传输再成功，目录结构也可能搬歪。

作者连“已经有同名目录”也写进了操作语义。BBN 的实现把这种情况视为错误，示例用 521 回应且不再动作。RFC 还分别列出旧版 FTP 中实际使用的回复码，以及按当时新版 RFC 765 设想的对应数字。旧版中新添的是 257，新版的建议值则是 251。1980 年的网络协议在不断换代，读这段历史，数字得放回它所属的版本。

RFC 765 本就希望 FTP 把不同主机的文件系统差异挡在用户之外，同时坦承协议还没有统一路径命名法。RFC 775 的办法很务实：先别逼所有机器改名字，让那台真正存放目录的服务器把名字说清楚。到 1985 年，RFC 959 已把去掉实验性 X 前缀的 MKD、RMD、PWD，以及上级目录命令 CDUP 列为可选命令。文件能跨网飞，目录仍得在某台机器上落地；落地后叫什么，得听房东的。