Zusammenfassung

  • Bei STRU R und MODE S leitete ein Nur-Einsen-Byte einen Zweibytecode ein: 1 stand für EOR, 2 für EOF und 3 für beide Grenzen am selben Punkt.
  • War das reservierte Byte selbst Nutzdatum, musste es wiederholt werden. Der Empfänger brauchte den ausgehandelten Kontext und Zustand über Lesegrenzen hinweg.
  • BLOCK und COMPRESSED legten dieselben Grenzen in Deskriptorbits. Datensatz, Textzeile, TCP-Segment und Lesepuffer blieben verschiedene Einheiten.

Ein Byte lang unentschieden

Zwei aufeinanderfolgende Nur-Einsen-Bytes sind nach der Dekodierung ein einziges Datenbyte. RFC 765 und RFC 959 reservierten den ersten Wert als Escape und gaben ihn durch Verdopplung an die Nutzdaten zurück.

Mit dem Folgewert 1 schließt das Paar einen Datensatz, mit 2 die Datei, mit 3 beides zusammen. Das erste Byte ist allein kein Beweis für Steuerung. Erst sein Nachbar und das zuvor gewählte STRU R vollenden die Bedeutung.

Die Rohübertragung kann deshalb länger als die rekonstruierte Datei sein, ohne Kompression oder Fehler. Jede literale Sentinelle verbraucht zwei Transferpositionen und erzeugt eine Datenposition.

Ordnung war noch keine Datensatzstruktur

FTP behandelte Struktur und Modus als getrennte Entscheidungen. STRU F erklärte die Datei zur kontinuierlichen Bytefolge; STRU R zu einer Folge von Datensätzen. MODE S bestimmte die Stromdarstellung auf der Datenverbindung.

Ein zuverlässiger geordneter Strom kennt die Grenzen der Quelldatensätze nicht. Für Record Structure waren daher alle EOR-Marken ausdrücklich, einschließlich der letzten. Der Sender übersetzte seine lokale Notation in die gemeinsame FTP-Form, der Empfänger in seine eigene Speicherform zurück.

Ein hosteigener Längenzähler war nicht portabel. Der Standard übertrug die Aussage „hier endet der Datensatz“, nicht das interne Plattenformat eines Mainframes.

Vier Fortsetzungen nach derselben Sentinelle

Normale Bytes kann der Parser ausgeben. Nach der Sentinelle wartet er auf den zweiten Wert. Dieser gibt ein literales Byte aus, erzeugt EOR, erzeugt EOF oder erzeugt beide Ereignisse.

Der kombinierte Code vermeidet einen erfundenen leeren Datensatz hinter dem letzten. Die Verdopplung lässt zugleich jeden möglichen Bytewert in der Datei zu. Eingebettete Steuerung bleibt umkehrbar.

Wer die Sentinelle sofort als Grenze deutet, zerstört literale Daten. Wer beide Bytes eines verdoppelten Paares erhält, fügt ein Byte hinzu. Rohbytes, rekonstruierte Daten und Strukturereignisse brauchen getrennte Zählung.

Eine Lesegrenze durfte das Paar zerschneiden

RFC 9293 beschreibt TCP als zuverlässigen, geordneten Bytestrom, nicht als FTP-Datensatzdienst. Eine Empfangsoperation kann an der Sentinelle enden und den Diskriminator erst beim nächsten Aufruf liefern.

Ob beide Bytes gemeinsam oder getrennt eintreffen, ändert nichts. TCP-Segmente und Pufferenden zu EOR zu erklären, würde vom Empfänger erzeugte Grenzen in die Datei einschreiben.

Auch ein ordentlicher Verbindungsschluss heilt keinen wartenden Escape-Zustand. Dann fehlt weiterhin das Byte, das die Darstellung vollenden sollte.

Unter STRU F war derselbe Wert gewöhnliches Datum

Mit STRU F + MODE S sind alle Bytes Daten; EOF entsteht durch Schließen der Datenverbindung. Das Nur-Einsen-Byte öffnet keine Sondergrammatik.

Ohne die zeitlich passende STRU-/MODE-Aushandlung ist ein Mitschnitt unvollständig. Dieselben Oktette können zwei Datenbytes, ein zitiertes Datenbyte oder eine Strukturmarke bedeuten.

Auch der Schluss hat andere Beweiskraft. Bei File Structure liefert die Verbindungsschließung EOF. Bei Record Structure muss der letzte EOR ausdrücklich vorhanden sein. „Verbindung erfolgreich beendet“ beweist die letzte Datensatzgrenze nicht.

Andere Modi verschoben die Grenze in Deskriptoren

BLOCK setzte vor jeden Datenblock eine Länge und Deskriptorbits. Ein Bit markierte EOR, ein anderes EOF; beide konnten gleichzeitig gelten. Weitere Bits standen für verdächtige Daten und Restart Marker.

COMPRESSED verwendete ebenfalls Deskriptorformen für EOR/EOF und ergänzte Darstellungen für Wiederholungen und Füllung. Die Grenzsemantik blieb, ihre Drahtform hing vom MODE ab.

Verschiedene Rohströme können dieselbe logische Datensatzkarte ergeben. Gleiche Rohbytes können unter anderer Aushandlung anders wirken. Belastbare Evidenz verbindet Steuerhistorie, Originalstrom und dekodierte Karte.

Zeilenende war kein allgemeines Satzende

FTP unterschied End-of-Line von End-of-Record. Ohne Record Structure konnte ASCII CRLF und EBCDIC NL als Zeilentrenner verwenden. Unter STRU R war EOR eine eigene Aussage.

Bei Ein-Zeile-pro-Datensatz-Dateien fallen beide zufällig zusammen. Ein Datensatz kann aber mehrere Zeilen enthalten, und eine Zeile kann nur Darstellung sein. Automatische Ersetzung erzeugt lesbaren Text und verändert dennoch die Quelle.

RFC 959 verlangte Record Structure für ASCII- und EBCDIC-Text und möglichst nützliche, umkehrbare Transformationen zwischen datei- und satzorientierten Hosts. Lesbarkeit ersetzte keinen Roundtrip der Grenzen.

Die spätere Mindestanforderung wurde enger

RFC 1123 machte Record Structure nur für Hosts verpflichtend, deren Dateisysteme sie unterstützten. Andere durften STRU R dennoch annehmen und den Strom wörtlich speichern.

Kodierung zu archivieren ist nicht dasselbe wie native Datensätze zu rekonstruieren. Sie kann eine spätere genaue Wiederherstellung ermöglichen, belegt aber keine unmittelbar nutzbare lokale Struktur. Rekonstruktion, Archivierung, Verflachung und Ablehnung sind getrennte Ergebnisse.

RFC 5797 und das IANA-Register der FTP-Befehle bewahren STRU und MODE als Basisparameter. Der Registereintrag prüft weder R noch Parserzustand oder Rückgewinnung.

Der Decoder gehört zur Beweiskette

Eine belastbare Aufzeichnung enthält TYPE, STRU, MODE, Hashes von Rohstrom und Daten, beide Längen, alle EOR-/EOF-Positionen, Verbindungsschluss, Parserendzustand und Rekonstruktionsergebnis.

Kanaris teilen das Paar über Leseaufrufe, mischen verdoppelte Literale mit allen drei Steuerformen und vergleichen STREAM und BLOCK für dieselbe Karte. Hängender Escape, unmöglicher Folgewert, fehlender letzter EOR oder Restzustand nach MODE-Wechsel sind Interpretationsfehler.

Das Byte erschien zweimal, damit FTP Steuerung reservieren konnte, ohne einen legalen Datenwert zu opfern. Nur der vollständige Kontext hielt beide Rollen auseinander.

Quellen