Summary

  • RFC 775 führte vier experimentelle FTP-Befehle für das Anlegen, Entfernen und Navigieren von Verzeichnissen bei der Fernwartung ein.
  • Nach dem Anlegen musste der Server seinen verwendbaren absoluten Pfad nennen. Auf TOPS-20 konnte der kurze Name aus XMKD beim anschließenden Wechsel in das Verzeichnis versagen.

Ein Verzeichnis anzulegen und es im nächsten Moment nicht zu finden, klingt nach einem schlecht gelaunten Rechner. RFC 775 führt genau diesen Fall vor: XMKD MYDIR funktioniert auf einem TOPS-20-Server, XCWD MYDIR kann danach fehlschlagen. Das Verzeichnis ist vorhanden. Sein vollständiger Name lautet im Beispiel <DFRANKLIN.MYDIR>.

Der Anlass war alltägliche Arbeit. BBN installierte und wartete für ein ARPA-Projekt Software auf mehreren DEC PDP-11 mit UNIX. Wer einen ganzen Verzeichnisbaum übertragen will, braucht am Ziel mehr als einen Kanal für Dateiinhalte. Er muss Verzeichnisse schaffen, betreten, verlassen und gegebenenfalls wieder entfernen können. Die BBN-Ingenieure ergänzten ihre FTP-Server deshalb um XMKD, XRMD, XPWD und XCUP. Der Befehl zum Wechsel ins Elternverzeichnis ersparte einem Programm die Kenntnis der jeweiligen Schreibweise für „eine Ebene höher“.

Genau darin lag die Schwierigkeit. UNIX, TOPS-20 und Multics kannten baumartige Verzeichnisse, aber keine gemeinsame Grammatik für Pfade. Wer auf TOPS-20 im Verzeichnis <DFRANKLIN> den Befehl XMKD MYDIR absetzt, bestellt ein Unterverzeichnis. Dessen spätere Adresse ist jedoch <DFRANKLIN.MYDIR>. Der Eingabetext beschreibt die gewünschte Handlung relativ zum aktuellen Ort; er muss nicht zugleich ein brauchbarer Schlüssel für das fertige Objekt sein.

RFC 775 machte daher die Antwort des Servers verbindlich. Nach erfolgreicher Erstellung sollte eine Zeile mit 257 folgen, darin der absolute Verzeichnisname in Anführungszeichen. Für UNIX zeigt das Dokument 257 "/usr/dm/child" directory created; TOPS-20 liefert seine eigene Schreibweise. Selbst ein Anführungszeichen innerhalb des Namens wird geregelt: In der Antwort erscheint es doppelt. Ein Programm kann so die Zeichenfolge sauber lesen, statt mitten im Pfad das Ende zu vermuten.

Für die Übertragung eines Baums ist das kein Schönheitsdetail. Das Programm legt am Ziel einen Zweig an, merkt sich die zurückgegebene Adresse, wechselt dorthin, kopiert Inhalte und kehrt zum übergeordneten Verzeichnis zurück. Wer den Pfad aus UNIX-Gewohnheit selbst zusammensetzt, kann bereits beim zweiten Schritt scheitern. Die Dateien wären transportierbar; ihre vorgesehene Ordnung wäre es dann nicht.

Auch ein bereits vorhandener Name erhielt eine klare Bedeutung. BBN behandelte ihn als Fehler und zeigte eine 521-Antwort ohne weitere Aktion. Die Tabelle im RFC unterscheidet zwischen den tatsächlich verwendeten Codes des älteren FTP und vorgeschlagenen Entsprechungen für das neuere RFC 765. 257 war im älteren Satz neu; für den neueren wurde 251 vorgeschlagen. Bei Protokollgeschichte ist die Versionsspalte Teil der Nachricht.

RFC 765 wollte Nutzer vor Unterschieden der Dateisysteme schützen, gestand aber zugleich ein, dass FTP keine einheitliche Pfadkonvention festlegte. RFC 775 löste einen Teil des Problems, ohne die Systeme auf eine Schreibweise festzulegen: Der Rechner, der das Verzeichnis tatsächlich anlegt, nennt dessen Adresse. RFC 959 führte 1985 MKD, RMD, PWD und CDUP als neue optionale Befehle auf. Das experimentelle X verschwand; das Bedürfnis nach einer verlässlichen Antwort blieb.