Summary

  • BBNは遠隔拠点の保守のため、ディレクトリー作成・削除・現在地表示・親への移動を行う四つの実験的FTPコマンドをRFC 775に記した。
  • 作成時に渡した短い名前は、作成後に通用する名前とは限らない。サーバーが返す絶対パスを使うことが、異なるOS間で階層を移す鍵だった。

「作成しました」「では入ります」「その名前の場所はありません」。1980年の端末がこんな会話をしても、故障と決めつけるのは早い。RFC 775 は、TOPS-20上で XMKD MYDIR が成功しても XCWD MYDIR が失敗し得ると説明する。出来上がった場所は消えていない。呼び方が違うのだ。

発端はBBNによるARPAの遠隔拠点保守だった。複数のDEC PDP-11にUNIXのソフトウェアを導入し、保守する。ファイルだけ転送できても、収めるディレクトリーの木を相手側で再現できなければ作業は片付かない。そこでサーバーに、作成の XMKD、削除の XRMD、現在地を答える XPWD、親へ戻る XCUP を加えた。親の表記法までクライアントに暗記させないため、XCUP は特に重宝する。

相手がUNIXなら、日頃のパス感覚で何とかなるかもしれない。だが当時のARPANETにはTOPS-20やMulticsもあった。どれも木構造を持てる一方、枝の名前の書き方は同じではない。RFCの例では、TOPS-20の <DFRANKLIN> にいるクライアントが XMKD MYDIR と頼むと、できるのは <DFRANKLIN.MYDIR>。作成依頼の引数は「ここに子を作る」という指定であり、完成品に再びアクセスするための完全な住所とは限らない。

解決策は返事を読むことだった。作成に成功したサーバーは、絶対パスを引用符で囲んだ 257 の応答を返す。UNIXの例なら 257 "/usr/dm/child" directory created。TOPS-20なら、そのホストが使える山括弧と点の表記になる。名前の中に引用符が入るときは二重にする、という細かな規則まである。プログラムが応答を機械的に読めなければ、せっかく返した住所も役に立たない。

階層ごと運ぶプログラムには、この住所が次の足場になる。子を作る、返された名を保存する、そこへ入る、ファイルや孫を置く、親へ戻る。ネットワークがファイルを正しく運んでも、行き先のOSの命名規則を勝手に推測すれば、配置が狂う。RFC 775が修理したのは、転送路よりも「作ったものをどう指すか」という会話だった。

同名のディレクトリーが既にある場合について、BBNの実装はエラーとして 521 を返し、何もしない例を示した。応答コードの表には当時使っていた古いFTPの値と、より新しい RFC 765 向けに提案した値が並ぶ。前者の新しい成功コードが 257、後者で想定したものは 251。時代の違う二つの数字を一つの約束事に混ぜてはいけない。

RFC 765はホストごとのファイルシステムの違いから利用者を守ることをFTPの目的に掲げながら、パス名の共通規則はまだ定めていないと認めていた。RFC 775はその空白を実務的に埋めた。後の RFC 959 には、Xのない MKD、RMD、PWD と親へ戻る CDUP が新しい任意コマンドとして載る。消えたのは実験の印。新しい場所の名を持ち主に聞く必要は残った。