Zusammenfassung

  • Mit ALLO meldete ein Client vor STOR oder APPE den Bedarf in logischen Bytes; für Record- oder Page-Strukturen konnte eine zweite Maximalgröße hinzukommen.
  • Brauchte ein Server keine Voraballokation, sollte er den Befehl als wirkungslose Operation behandeln und mit dem positiven Abschluss 202 den weiteren Ablauf erlauben.
  • Dieser Abschluss belegte Prozesskompatibilität, nicht reservierte Kapazität. Erst Datentransfer, Endantwort, Speicherzustand und resultierende Datei stützten eine stärkere Aussage.

Ein Planungswert traf auf verschiedene Dateisysteme

Wer eine große Datei versendet, kennt häufig ihre Länge. Eine frühe Meldung könnte dem Empfänger erlauben, Platz zu sichern, bevor Netzzeit verbraucht wird. Doch die frühen Internet-Hosts besaßen keine einheitliche Speicherverwaltung. Manche verlangten eine Zuteilung vor dem Schreiben, andere ließen Dateien während der Aufnahme wachsen und kannten keinen gesonderten Reservierungsschritt.

Der RFC 354 von 1972 nahm beide Fälle in ALLOCATE (ALLO) auf. Manche Server konnten den Befehl benötigen, um ausreichend Speicher für die neue Datei zu reservieren. Das Dezimalargument bezeichnete Bytes in der gewählten Bytegröße; anschließend sollte STORE oder APPEND folgen.

Server, die keine vorherige Erklärung der Maximalgröße verlangten, sollten ALLO dagegen als wirkungslose Operation behandeln. Das Protokoll zwang ihnen kein fremdes Plattenmodell auf. Der Client durfte einen Bedarf formulieren, während der Server entschied, ob dieser Bedarf in eine lokale Reservierung übersetzt werden musste.

Der RFC 765 von 1980 präzisierte die Größe als logische Bytes. Bei Record- oder Page-Struktur durfte ein zweites Dezimalargument die maximale Record- oder Seitengröße angeben, getrennt durch Leerzeichen, R, Leerzeichen. War nur diese zweite Größe für den Server relevant, sollte er einen Dummywert im ersten Feld akzeptieren und ignorieren.

Schon diese Grammatik warnt vor einer Verwechslung. Ein logisches Byte ist nicht automatisch ein Dateisystemblock. Der deklarierte Wert ist weder eine Messung des freien Platzes noch ein Quotenabbuchungsbeleg, weder die komprimierte Drahtlänge noch die dauerhaft belegte Medienmenge. Er ist ein Hinweis in der aktiven FTP-Darstellung.

Das positive 202 bescheinigte eine überflüssige Handlung

Der RFC 959 übernahm 1985 den Befehl mit einer Pflichtzahl und der optionalen Form R plus zweiter Zahl. STOR oder APPE musste folgen; ohne Bedarf an einer Vorabdeklaration sollte ALLO als NOOP gelten.

Die Antwortregeln machen die Absicht sichtbar. Ein erfolgreich ausgeführter Befehl wie TYPE oder ALLO, der dem User-Prozess keine neue Information bietet, kann 200 erhalten. Ist ALLO auf einem bestimmten System nicht implementiert, weil es dort keine Relevanz besitzt, ist trotzdem ein positiver Abschluss erwünscht. Ein einfacher Client weiß dann, dass er seinen Ablauf fortsetzen kann. Dafür dient 202, beispielhaft erläutert mit „No storage allocation necessary“.

Die allgemeine Beschreibung lautet: Befehl nicht implementiert, an diesem Standort überflüssig. Das ist kein Fehler, der grün eingefärbt wurde. Der Server erklärt offen, dass die Handlung nicht stattgefunden hat, und zugleich, dass ihr Ausbleiben das Nutzerziel nicht blockiert. Erfolgreich war die Fortsetzung, nicht der Nachweis einer Reserve.

Ein nicht implementierter, nicht standortspezifischer Vorgang würde 502 auslösen; ein nicht unterstützter Parameter eines vorhandenen Befehls kann 504 erhalten. FTP unterschied also, warum etwas nicht geschah und ob dieser Umstand den Auftrag verhindern musste.

Auch 200 ist ohne lokale Belege kein universeller Speicherbeleg. Ein Server kann tatsächlich reserviert haben. Der Code nennt aber weder physische Blöcke noch Gültigkeitsdauer, konkurrierende Zugriffe oder Quotenregeln. Der RFC ordnet ihn gerade einem Erfolg ohne neue Information zu. Mehr Semantik muss die Implementierung liefern.

Hinter STOR wartete der eigentliche Kapazitätstest

ALLO bewegt keine Dateidaten. Erst STOR fordert den Server auf, Daten aus der Datenverbindung anzunehmen und unter einem Pfad zu speichern. Besteht die Datei, soll der neue Inhalt sie ersetzen; fehlt sie, soll sie angelegt werden. Nun treffen Protokollabsicht, Verbindung, Rechte, Pfad und Speichersystem aufeinander.

Die Antwortfolge trennt Start und Ende. 125 sagt, dass die Datenverbindung bereits offen ist und die Übertragung beginnt. 150 kündigt an, dass der Dateistatus passt und eine Datenverbindung geöffnet wird. Beides sind vorläufige Antworten. Ein positiver Abschluss kann später 226 oder 250 sein; Verbindungs-, lokale Verarbeitungs-, Pfad- und Speicherfehler besitzen andere Codes.

452 bedeutet, dass die verlangte Aktion wegen unzureichenden System-Speicherplatzes nicht ausgeführt wurde. 552 bricht die Dateiaktion ab, weil eine Speicherzuteilung, etwa für das aktuelle Verzeichnis oder Dataset, überschritten wurde. Ein früheres 202 widerspricht diesen Antworten nicht. Keine Voraballokation zu benötigen heißt nicht, beim tatsächlichen Schreiben niemals an eine Grenze zu stoßen.

Die Belegkraft steigt stufenweise. ALLO dokumentiert die Client-Angabe. 202 dokumentiert die Serverentscheidung, ohne Reservierung fortzufahren. 125 oder 150 dokumentiert den Eintritt in die Datenphase. Erst eine passende Endantwort und die Prüfung der Datei stützen die Aussage, der erwartete Inhalt sei gespeichert worden.

Der RFC 3659 zieht bei maschinenlesbaren Berechtigungen eine verwandte Grenze. Eine gesetzte Schreibberechtigung garantiert nie, dass der zugehörige Befehl funktioniert; systemspezifische Beschränkungen wie verfügbarer Platz können ihn noch scheitern lassen. Die Berechtigung ist nur ein Hinweis. Das ist keine neue ALLO-Definition, aber dieselbe Warnung vor der Gleichsetzung von Möglichkeit und Ergebnis.

Optional bedeutete nicht unerreichbar

Der RFC 1123 ordnete die Server-Unterstützung von ALLO 1989 der optionalen Kategorie zu. Zugleich verlangte er vom User-FTP ein QUOTE-Kommando, das eine beliebige Zeichenfolge an den Server sendet und alle Antworten anzeigt.

Die Erläuterung nennt SITE und ALLO ausdrücklich. Selbst wenn der Client eine standortspezifische oder optionale Fähigkeit nicht als eigenes Bedienelement kannte, konnte der Nutzer sie ansprechen. So musste der allgemeine Client nicht jede lokale Tradition fest einbauen, und der Server konnte Besonderheiten beobachtbar anbieten.

Das IANA-Register der FTP-Befehle und -Erweiterungen führt ALLO weiterhin als Basisbefehl „Allocate“ mit Verweis auf RFC 959. Das Register klärt Wort und Referenz. Es beweist weder Implementierung noch Reservierung, freie Kapazität oder den Abschluss einer konkreten Übertragung.

Eine brauchbare Spur endet nicht beim ersten Grün

„ALLO erfolgreich“ ist für ein Audit zu grob. Aufbewahrt werden sollten die genaue Befehlszeile, beide Zahlen, aktives TYPE und STRU, numerischer Code und vollständiger Antworttext. 200 und 202 sind beide positiv, tragen aber unterschiedliche Entscheidungen.

Danach muss die Spur zum folgenden STOR oder APPE reichen. Öffnete sich die Datenverbindung? Wie viele Bytes gingen über die Leitung? Trat ein Abbruch auf? Welche Endantwort kam? Existiert die Zieldatei in erwarteter Größe und mit erwarteter Prüfsumme? Für Kapazitätsfragen gehören freier Platz, Konto- und Verzeichnisquote sowie konkurrierende Last zum gleichen Zeitpunkt hinzu.

Auch die Abbildung logischer Bytes auf lokale Nutzung gehört sichtbar gemacht. Record-Struktur, Zeichenrepräsentation, Sparse-Dateien, Metadaten und temporäres Schreiben können die tatsächliche Belegung verändern. Der Protokollwert koordiniert die Planung, ersetzt aber keine Speicherbuchhaltung.

Selbst ein positiver FTP-Abschluss verspricht nicht automatisch dauerhafte Aufbewahrung, Replikation oder spätere Wiederherstellbarkeit. Wo diese Eigenschaften zählen, wird das Objekt erneut gelesen, gehasht und gegebenenfalls aus einer Kopie wiederhergestellt. Die Lehre von ALLO lautet nicht, Antworten zu misstrauen, sondern ihre Aussage auf die jeweilige Phase zu begrenzen.

Quellen