Zusammenfassung

  • FTP teilte eine Umbenennung in RNFR und RNTO; 350 nach dem ersten Befehl war eine positive Zwischenantwort und kein Beleg für einen geänderten Namen.
  • RFC 3659 machte getrennte Fähigkeiten am Quellobjekt und Zielverzeichnis sowie eine optionale Unique-Evidenz für das Objekt unter wechselnden Namen sichtbar.
  • Die Standards regeln Befehlszustand und Antwortbedeutung, versprechen aber weder Atomarität noch Dauerhaftigkeit, Kollisionspolitik, Absturzsicherheit oder heutige Bereitstellung.

Positiv, aber noch nicht geschehen

Der Client sendet RNFR old-name. Der Server antwortet 350 Requested file action pending further information. Ein Monitoring, das nur Fehler von Nichtfehlern trennt, färbt den Vorgang grün.

Die Datei kann dennoch unverändert unter ihrem alten Namen liegen. RFC 959 definiert 3xx als positive Zwischenantwort: Der Befehl wurde akzeptiert, die angeforderte Aktion bleibt jedoch in der Schwebe, bis der Client weitere Informationen liefert. Bei der Umbenennung ist das der neue Pfad in RNTO.

Schon RFC 765 beschreibt das Paar so. RNFR bezeichnet die umzubenennende Datei und muss unmittelbar von RNTO gefolgt werden. Der zweite Befehl nennt den neuen Pfad für die Datei aus dem vorherigen Befehl. Erst beide zusammen bewirken die Umbenennung.

FTP gab dem Warten damit eine protokollarische Form. Eine Antwort konnte den Fortgang erlauben, ohne einen Abschluss vorzutäuschen.

Gespeichert wurde Kontext, keine fertige Transaktion

RNFR und RNTO bilden eine sequentielle Befehlsgruppe. Scheitert ein Schritt, muss die ganze Folge von vorn wiederholt werden. Der Server merkt sich im Kontrollkanal genug Quellkontext, um den nächsten Zielbefehl zu verstehen.

Daraus folgt weder eine Quellsperre noch eine Zielreservierung oder ein dauerhaft fortsetzbarer Transaktionsbeleg. „Unmittelbar“ bindet das Ziel an den direkt vorhergehenden Quellbefehl. Fehlt die richtige Reihenfolge, ist für RNTO die Antwort 503 Bad sequence of commands vorgesehen.

Eine belastbare Spur braucht daher Sitzungskennung und Reihenfolge. Zwei Logzeilen mit altem und neuem Pfad beweisen nichts, wenn sie aus unterschiedlichen Verbindungen stammen oder ihre Nachbarschaft nicht erhalten blieb.

Absicht, angenommener Zwischenzustand und Ergebnis sind drei Tatsachen. Der Client benennt eine Quelle. Der Server nimmt sie für die Fortsetzung an. Erst die abschließende Antwort auf das Ziel sagt, ob die Mutation auf Protokollebene vollendet wurde.

350 und 250 tragen verschiedene Aussagen

RFC 959 nennt 2xx eine positive Beendigung: Die angeforderte Aktion wurde erfolgreich abgeschlossen, eine neue Anfrage kann beginnen. 250 bedeutet konkret, dass die angeforderte Dateiaktion in Ordnung und abgeschlossen ist. Bei 350 fehlt weiterhin Information.

Wer beide als Erfolg aggregiert, löscht die Zustandssemantik der Antwortklassen. 350 erlaubt den nächsten Schritt; 250 belegt den Abschluss dieses Austauschs.

Geht die letzte Antwort verloren, kennt der Client das Ergebnis nicht. Er sollte den Namensraum abgleichen, bevor er eine wirkungsvolle Operation wiederholt. Die alte 350-Antwort ist kein dauerhaftes Transaktionstoken. Die standardisierte Wiederherstellung führt zurück zum Anfang der Befehlsfolge.

Quelle und Ziel haben nicht dieselbe Autorität

RFC 3659 machte mit dem MLSx-Fakt perm deutlicher, dass zwei Berechtigungsflächen beteiligt sind. f an einem Objekt zeigt, dass der aktuelle FTP-Benutzer es als Gegenstand von RNFR verwenden kann. c an einem Verzeichnis zeigt, dass dort Dateien erzeugt werden können und RNTO für Namen darin wahrscheinlich gelingt.

Die erste Fähigkeit gehört zum Quellobjekt, die zweite zum Zielcontainer. Wer einen bestehenden Namen aufgeben darf, darf nicht automatisch in jedem Verzeichnis einen neuen schaffen.

„Wahrscheinlich“ ist keine Zusage. Ein Listenfakt beschreibt eine erwartete Fähigkeit zum Beobachtungszeitpunkt. Er reserviert keinen Namen, friert keine Richtlinie ein und beseitigt keine Konkurrenz. Die endgültige Befehlsantwort bleibt entscheidend.

Ein Objektindiz über den Namenswechsel hinweg

Dieselbe RFC definierte den optionalen Fakt Unique. Wenn ein Server ihn anbietet, sollen Pfade auf dieselbe zugrunde liegende Datei denselben und verschiedene Dateien unterschiedliche opake Werte tragen. Mindestens für die Lebensdauer der Kontrollverbindung soll die Zuordnung stabil bleiben.

Das Beispiel beginnt mit mlst.c und einem Unique-Wert. Auf RNFR mlst.c folgt 350, auf RNTO list.c folgt 250. Danach erscheint list.c mit demselben Wert. Der Pfad änderte sich, das begrenzte Objektindiz des Servers blieb bestehen.

Unique ist keine globale Kennung, kein Inhalts-Hash und keine dauerhafte Identität. Server müssen auch keinen bestimmten MLSx-Fakt unterstützen. Das Beispiel zeigt eine mögliche Evidenzkombination: Die Abschlussantwort belegt die Protokollaktion; ein verfügbarer Unique-Wert stärkt innerhalb seines Geltungsbereichs die Aussage, dass alter und neuer Name dasselbe zugrunde liegende Objekt bezeichnen.

Pflichtwortschatz ohne Dateisystemgarantie

RFC 1123 führte RNFR und RNTO in den FTP-Hostanforderungen fort. RFC 5797 ordnete beide als verpflichtende Basisbefehle ein; das IANA-Register für FTP-Befehle bewahrt die Einträge.

Das belegt einen interoperablen Wortschatz, aber keinen Vertrag des Speichersystems. Ob gleichzeitige Leser einen atomaren Wechsel sehen, ein bestehendes Ziel überschrieben wird, der Zustand dauerhaft geschrieben ist, ein Absturz überstanden wird oder Dateisystemgrenzen erlaubt sind, bleibt offen. Auch die Freigabe auf einem bestimmten heutigen Server folgt nicht aus dem Register.

Die enge Zusage ist wertvoll genug: FTP unterscheidet die angenommene Quellstufe von der abgeschlossenen Umbenennung. Alles darunter braucht eigene Implementierungs- und Betriebsevidenz.

Eine Datei zwischen zwei Namen

Auch moderne Kontrollschnittstellen akzeptieren Vorschläge, bevor sie Änderungen festschreiben. Ein gutes System benennt den Zwischenzustand, bindet ihn an Sitzung oder Transaktion, erklärt seine Ungültigkeitsbedingungen und verwendet Abschlusswörter nur für Abschlussbelege.

Es trennt zudem Quellberechtigung, Zielberechtigung und Objektidentität. Ein einziges Erfolgsflag oder eine pauschale Bearbeitungsrolle verwischt sowohl Audit als auch Delegation.

350 war kein schwacher Erfolg. Es war ein präzise nicht endgültiger Erfolg. Die Datei war in eine Befehlsfolge eingetreten, nicht in einen neuen Pfad. Die Umbenennung hatte noch nicht stattgefunden — genau das sagte der Code.

Quellen