要約

  • FTPは名前変更をRNFRとRNTOに分け、RNFRへの350を完了ではなく「追加情報待ち」の肯定中間応答とした。
  • 後年のRFC 3659は、変更元に必要な能力、変更先ディレクトリに必要な能力、任意のオブジェクト同一性情報を別々の事実として表現した。
  • 規格が保証するのは命令順序と応答の意味であり、原子性、永続性、上書き方針、競合回避、現在の実装状況ではない。

緑色にしてはいけない350

クライアントがRNFR old-nameを送る。サーバーは350 Requested file action pending further informationと答える。数字は肯定側なので、単純な監視なら成功件数に加えてしまう。

しかし、この時点では名前変更は終わっていない。RFC 959における3xxは肯定中間応答である。命令は受理されたが、要求された動作は保留され、クライアントからの追加情報を待つ。ここで不足しているのは、RNTOが与える新しいパス名だ。

RFC 765にも既に同じ骨格がある。RNFRは変更するファイルを指定し、必ず直後にRNTOが続く。RNTOは直前のファイルに新しいパスを指定する。二つが組になって初めてrenameを起こす。

肯定は常に完了を意味しない。FTPはその違いを文章だけでなく、応答クラスそのものに刻んだ。

サーバーが保持したのは文脈だった

規格はRNFRとRNTOを順序を持つ命令群として扱う。途中で失敗すれば、一連の命令を最初からやり直す。この規則から読み取れるのは、サーバーが次の命令を解釈するための変更元文脈を制御セッション内に保持しているということだ。

そこからロック、変更先の予約、耐久的な取引IDを推測することはできない。RNTOは「直前」のRNFRで名指されたファイルを参照する。適切な前段がなければ、503 Bad sequence of commandsが返り得る。

監査記録には接続と順序が欠かせない。別々のログ行に旧名と新名があっても、同じ制御セッションで隣接していた証拠がなければ、どの変更元と変更先が対になったのかは分からない。

意図、待機状態、完了は三つの異なる事実である。RNFRはクライアントの意図を示す。350はサーバーが続きを受け取れる状態に入ったことを示す。変更の成否を語るのはRNTOの最終応答である。

250は何を追加したのか

RFC 959は2xxを肯定完了と定義し、要求された動作が成功して新しい要求を開始できる状態だとする。250は要求されたファイル動作が正常に完了したことを明記する。一方の350には、なお追加情報が必要だと書かれている。

したがって、両方を一つの「成功」欄へ折り畳むと、最も重要な状態差を捨てることになる。350は次へ進む許可、250はその交換における完了の証拠だ。

最終応答が失われた場合も区別は役に立つ。クライアントは失敗を確定できず、結果不明として名前空間を照合する必要がある。以前の350を再利用できる永続トークンとみなしてはならない。規格の回復手順は、むしろ変更元から文脈を作り直す方向を指す。

二つのパスには二つの権限面がある

RFC 3659のMLSx perm factは、元来二つあった判断面を見える形にした。オブジェクトに付くfは、現在のFTP利用者がそれをRNFRの対象にできることを示す。ディレクトリに付くcは、そこでファイルを作成でき、その中の名前へのRNTOが成功する見込みを示す。

一方は変更元オブジェクト、もう一方は変更先コンテナに属する。変更元を手放す権限があるからといって、どのディレクトリにも新しい名前を作れるわけではない。

しかもRFCが使うのは「成功する見込み」であり、保証ではない。表示時点の能力情報は、名前の予約でも最終認可でもない。競合や方針変更を消せないため、最後の応答が依然として必要になる。

同じファイルを名前の外側から見る

同じRFCは任意のUnique factも定義した。対応するサーバーでは、同じ基礎ファイルを指すパス名に同じ不透明値を与え、別のファイルには別の値を与える。その対応は少なくとも制御接続の存続中、一貫しているべきだとされた。

例ではmlst.cに一つのUnique値が付く。RNFR mlst.cが350、RNTO list.cが250を受けた後、list.cにも同じ値が示される。パス名は変わったが、サーバーが提供した限定的なオブジェクト手掛かりは続いている。

この値は世界共通IDでも内容ハッシュでも永久識別子でもない。サーバーに特定のMLSx factを提供する義務もない。重要なのは、命令応答とオブジェクト比較が別の証拠だという点である。250はプロトコル動作を示し、Uniqueが利用できれば新旧名の背後にある対象の連続性を補強できる。

必須命令でも記憶装置の契約ではない

RFC 1123はRNFRとRNTOをFTPホスト要件に残した。RFC 5797は両方をbaseの必須命令として整理し、IANAのFTP Commands and Extensionsも登録を維持している。

この系譜は共通語彙を証明するが、ファイルシステムの取引仕様ではない。並行読者に対する原子性、保存媒体への永続化、既存の変更先を上書きするか、障害復旧やファイルシステム境界の扱いは、これらの登録からは分からない。特定サーバーが現在命令を許可している証拠にもならない。

狭いが確かな歴史的事実は、FTPが変更元の受理と名前変更の完了を異なる状態として相互運用可能にしたことだ。

名前の間にあったファイル

現代の制御APIも、提案を受け入れた時点と変更を確定した時点の間に状態を持つ。良い設計は、その状態の名前、有効期間、所属するセッション、無効化条件、完了を証明する応答を公開する。

さらに、変更元を操作する能力、変更先を作る能力、対象そのものの同一性を分ける。これらを一つの成功フラグや「編集可能」という権限にまとめれば、監査と委任の両方が粗くなる。

FTPの350は不完全な成功ではない。非最終であることを正確に伝える成功だった。ファイルは命令列の中に入っただけで、新しい名前にはまだ入っていなかった。

出典