Zusammenfassung

  • FTP verteilte einen Dateivorgang auf Steuer- und Datenverbindung. Eine 1yz-Antwort war positiv, aber vorläufig; der Befehl blieb bis zu einer späteren Abschlussantwort offen.
  • Die Datenverbindung konnte nach normalem EOF, ABOR, geänderter Portangabe, Verlust der Steuerverbindung oder einem nicht behebbaren Fehler schließen. Dasselbe Transportereignis hatte daher mehrere mögliche Bedeutungen.
  • Bei aktivem ABOR beendet 426 den ursprünglichen Transfer negativ; das folgende 226 beendet den Abbruchbefehl positiv. Wer nur den letzten Code behält, verbucht eine gelungene Stornierung als gelungenen Transfer.

Der Datenzähler kannte den Auftrag nicht

Erwartete Größe erreicht, Datei sichtbar, Verbindung geordnet geschlossen: Diese Kombination lädt zu einem grünen Status ein. Sie beschreibt jedoch nur einen Teil des Vorgangs. FTP führte Befehle und nummerierte Antworten auf einer langlebigen Steuerverbindung, während eine eigene Datenverbindung Verzeichnislisten oder Dateiinhalte trug.

Der Datentransferprozess sah Verbindungsaufbau, Oktette, EOF und Transportfehler. Der Protokollinterpreter wusste, welcher Befehl lief, ob bereits eine vorläufige Antwort gesendet worden war und welche Antwort den Vorgang beendete. Beide Zeitachsen gehörten zusammen, waren aber keine austauschbaren Belege.

Diese Trennung war gewollt. Der Steuerdialog konnte bestehen bleiben, während Datenwege für einzelne Aktionen entstanden und verschwanden. Ihre Flexibilität hatte eine klare Bedingung: Ein Ereignis der unteren Schicht durfte nicht ohne Weiteres die Bedeutung des Anwendungsergebnisses übernehmen.

Schon frühes FTP kannte zwei geschlossene Ausgänge

RFC 354 vom Juli 1972 führte 252 FTP transfer completed correctly. Daneben stand 452 FTP: File transfer incomplete, data connection closed.

In beiden Fällen konnte die Datenverbindung geschlossen sein. Der Unterschied lag in der Aussage des Servers über die Dateiaktion. Damit widersprach bereits die frühe Spezifikation der später beliebten Abkürzung, ein ordentlicher Verbindungsabbau sei ein Erfolgsbeleg.

FTP verband Rechner mit unterschiedlichen Darstellungen, logischen Bytegrößen, Dateistrukturen und Speichermodellen. Der Server koordinierte einen Protokollinterpreter, einen Datentransferprozess und eine lokale Dateioperation. Eine beobachtete Bytefolge konnte diese Schichten nicht vollständig vertreten.

Freie Antworttexte eigneten sich dennoch schlecht für Maschinen. Der Client musste aus den Ziffern erkennen, ob er warten, weitere Angaben liefern, neu anfragen oder den Vorgang abschließen durfte.

Die erste Ziffer wurde zur Zustandsregel

RFC 640 ordnete 1974 die Antwortklassen neu. 1yz bedeutet positiv-vorläufig: Die Aktion hat begonnen, ist aber unvollständig und eine weitere Antwort folgt. 2yz ist positiver Abschluss. 3yz wartet nach Annahme des ersten Schritts auf zusätzliche Information. 4yz und 5yz schließen die Anfrage negativ ab, mit unterschiedlicher Aussicht auf Wiederholung.

„Positiv“ war somit keine einheitliche Erfolgsklasse. 150 konnte den Client zum Datenweg schicken und zugleich verbieten, den Befehl als erledigt abzulegen.

RFC 640 zog zudem den Zeitpunkt der vorläufigen Antwort vor. Der Server durfte sie senden, wenn der Transfer möglich war und eine Datenverbindung bestand oder versucht werden sollte. Das beschleunigte die Abfolge, engte aber die Beweiskraft ein: Bereitschaft war weder Verbindungsaufbau noch Transferabschluss.

Auf 125 oder 150 musste noch ein Ende folgen

RFC 765 und RFC 959 von 1985 bewahrten die Zweiteilung. RFC 959 erlaubt höchstens eine 1yz-Antwort je Befehl; anschließend muss eine Abschlussantwort kommen.

Bei Dateibefehlen sagt 125, dass die Datenverbindung bereits offen ist und der Transfer beginnt. 150 sagt, dass der Dateistatus in Ordnung ist und der Server die Datenverbindung öffnen wird. Am Ende stehen 226 oder 250, oder passende Fehler wie 425, 426, 451, 551 und 552.

Eine Aufzeichnung mit 150, erwarteter Bytezahl und FIN bleibt auf FTP-Ebene unvollständig, wenn die Abschlussantwort fehlt. Umgekehrt verschwindet ein negativer Abschluss nicht, weil der Zähler zufällig stimmt. Der Widerspruch ist selbst ein wichtiger Befund.

Darum wartet ein Client normalerweise vor dem nächsten gewöhnlichen Befehl. Der vorherige Zustandsübergang läuft noch. ABOR und STAT benötigen Sonderbehandlung gerade deshalb, weil sie laufende Arbeit erreichen oder beobachten sollen.

Eine Schließung hatte mehrere Ursachen

RFC 959 nennt verschiedene Gründe, aus denen der Server die Datenverbindung schließt: normaler Transferabschluss, Empfang eines Abbruchs, Änderung der Portangabe, reguläres oder irreguläres Ende der Steuerverbindung und ein nicht behebbarer Fehler.

Auf TCP-Ebene können sie ähnlich aussehen; für den Befehl sind sie unvereinbar. Selbst ein geordneter FIN belegt weder die richtige Dateigrenze noch den lokalen Erfolg, und er schließt einen absichtlichen Abbruch nicht aus.

Im Stream-Modus kann das Schließen das Dateiende markieren. Das ist eine Rahmungsregel, kein allumfassender Erfolgsnachweis. Beim Wiederanlauf wird die Grenze sichtbar: Ohne Steuerkontext kann dieselbe Schließung für normales Ende oder vorzeitige Unterbrechung stehen.

Ein Monitor sollte daher „Daten-EOF/Schließung beobachtet“ und „FTP-Befehl mit Code X abgeschlossen“ als zwei Ereignisse speichern. Zeitliche Nähe hebt ihre unterschiedlichen Zuständigkeiten nicht auf.

Ein positives 226 konnte den Abbruch abschließen

Trifft ABOR ein, nachdem der frühere Dienst bereits abgeschlossen ist, bleibt nichts zu stoppen. Der Server kann trotzdem 226 senden, weil er den Abbruchbefehl bearbeitet hat. Diese Antwort gehört zu ABOR, nicht als neues Gütesiegel zur Datei.

Läuft der Transfer noch, verlangt RFC 959 zwei Antworten. Zuerst meldet 426, dass die Datenverbindung geschlossen und der ursprüngliche Transfer abgebrochen wurde. Danach meldet 226, dass der Befehl ABOR erfolgreich bearbeitet wurde.

Die Zuordnung lautet:

  1. ursprünglicher Transfer → negativer Abschluss (426);
  2. Abbruchanforderung → positiver Abschluss (226).

Nur den letzten Code zu speichern schreibt den Erfolg dem falschen Auftrag gut. Beide Codes dem Transfer zuzuordnen unterschlägt dagegen, dass der Abbruch funktionierte. Reihenfolge und Aktionszugehörigkeit sind Bestandteil der Semantik.

Die Aussage von 226 endete an der FTP-Grenze

Beim gewöhnlichen Transfer besagt 226, dass die Datenverbindung schließt und die angeforderte Dateiaktion erfolgreich war. Der Code enthält keinen Inhaltsdigest und keine Versionskennung. Er garantiert weder dauerhafte Speicherung noch Backup, spätere Berechtigung, Verbrauch durch eine Anwendung oder geschäftliche Erfüllung.

Stärkere Aussagen benötigen eigene Belege: Hash für Inhalt, lokaler Commit für Persistenz, unveränderliche Objektkennung für Version und Anwendungsbestätigung für nachgelagerte Annahme.

Auch ein fehlendes 226 beweist nicht, dass keine Wirkung eingetreten ist. Der Server kann eine Datei geschrieben und danach die Steuerverbindung verloren haben. Blindes Wiederholen kann duplizieren oder überschreiben. Der ehrliche Status lautet dann „FTP-Ergebnis unbekannt“.

Der Steuerverlauf gehörte in den Transfernachweis

Eine prüfbare Aufzeichnung bewahrt Befehl und Reihenfolge, 125/150, Datenendpunkt, Aufbauresultat, Bytes, EOF, bekannte Schließursache, alle Abschlussantworten sowie den Zeitpunkt von ABOR oder STAT.

Daneben stehen Tatsachen, die FTP nicht bestätigt: Darstellung und Modus, Pfadauflösung, lokale Dateioperation, Persistenz, Digest und Objektversion. Sie ergänzen einander; sie ersetzen sich nicht.

Ein einziges done ist zu grob. Sinnvolle Zustände sind: vorläufig angenommen, Datenverbindung ausstehend, Daten aktiv, Daten geschlossen und Abschluss ausstehend, Transfer positiv beendet, Transfer negativ beendet, Abbruch angefordert, ursprünglicher Transfer abgebrochen, Abbruch bearbeitet und Steuerergebnis unbekannt.

Nach der Verdichtung zu einem Booleschen Wert lässt sich nicht mehr herstellen, welche Aktion der letzte Code beendete. Der irreversible Verlust betrifft die Bedeutung, nicht den Socket.

Quellen und Beweisgrenze

Die Darstellung stützt sich auf RFC 354, RFC 542, RFC 640, RFC 765, RFC 959 und RFC 1123. Sie belegen Antwortklassen, getrennte Verbindungen, Schließgründe und die ABOR-Sequenz.

RFC 1123 stellte 1989 fest, dass Restart, ABOR und Block-Modus nützlich, aber nicht weit verbreitet waren. Das ist eine historische Beobachtung und keine heutige Marktvermessung. Die Quellen belegen weder aktuelles Produktverhalten noch Dateisystemdauerhaftigkeit.