Dateitransfer und Dateiaustausch

Dateitransfer ist eine Kette aus Medium, Verbindung, Protokoll und Dateisemantik

Dateien wandern nicht abstrakt von „Computer A“ zu „Computer B“. Jeder Transfer besitzt mindestens eine physische oder logische Transportstrecke, ein Verfahren zur Übertragung, eine Dateidarstellung und ein Zielsystem, das Namen, Zeitstempel, Attribute und Inhalte wieder interpretieren muss.

Ein serielles Nullmodemkabel löst beispielsweise nur die elektrische Verbindung. Erst ein Terminalprogramm oder Protokoll wie XMODEM, Kermit oder ZMODEM regelt Blockbildung, Fehlererkennung und Wiederholung. Ein USB-Kabel wiederum kann Mass Storage, MTP, Netzwerk oder etwas völlig anderes transportieren.

Die Geschichte des Dateiaustauschs ist deshalb eine Geschichte von Übersetzungen: elektrische Pegel, Handshakes, Paketgrenzen, Dateisysteme, Zeichensätze, Metadaten, Namensregeln und Sicherheitsmodelle müssen auf beiden Seiten zusammenpassen.

Vier Ebenen sauber auseinanderhalten

Die physische Ebene bestimmt Stecker, Pegel und Signale. Die Link- oder Geräteschicht organisiert Frames und Gerätekommunikation. Ein Transferprotokoll regelt Datei- oder Blockübertragung. Darüber entscheidet das Dateisystem, wie ein empfangenes Objekt gespeichert wird.

Probleme entstehen häufig, wenn diese Ebenen vermischt werden. RS-232 ist kein Dateiformat, Ethernet ist kein Dateifreigabeprotokoll, TCP ist kein Dateiarchiv und USB-C sagt allein nichts über die tatsächlich verwendete Datenfunktion aus.

Eine technische Dokumentation sollte deshalb immer notieren, über welchen Kanal, mit welchem Protokoll und in welchem Dateiformat übertragen wurde.

Ein erfolgreicher Kopiervorgang ist noch keine bewiesene Identität

Ein Programm kann „Transfer abgeschlossen“ melden, obwohl Quelle und Ziel später durch Medienfehler, falschen Textmodus oder nachträgliche Änderungen voneinander abweichen.

Für wichtige Daten sind Dateigröße und kryptografischer Hash die belastbarere Kontrolle. Bei historischen Protokollen steht oft nur eine Blockprüfsumme oder CRC zur Verfügung; nach dem Transfer kann zusätzlich ein moderner Hash gebildet werden.

Quellhash, Zielhash und verwendete Übertragungsart sollten bei archivwürdigen Daten gemeinsam dokumentiert werden.

Serielle Übertragung – Bits nacheinander über wenige Leitungen

Asynchrone serielle Kommunikation überträgt Zeichen als Folge von Startbit, Datenbits, optionaler Parität und Stopbit. Beide Seiten müssen Baudrate und Zeichenformat passend einstellen.

Die klassische PC-UART-Welt verwendet Konfigurationen wie 9600 8N1 oder 19200 8N1. 8N1 bedeutet acht Datenbits, keine Parität und ein Stopbit.

Die serielle Leitung selbst kennt noch keine Dateien. Sie liefert nur einen Byte- beziehungsweise Zeichenstrom, den ein höheres Protokoll strukturiert.

Baud und Bit pro Sekunde

Baud bezeichnet Symbolwechsel pro Sekunde. Bei einfacher binärer serieller UART-Übertragung entspricht ein Symbol typischerweise einem Bit, weshalb Baudrate und Bitrate dort oft zahlenmäßig gleich sind.

Bei Modems mit komplexerer Modulation trägt ein Symbol mehrere Bits. Dann sind 2400 Baud und 9600 bit/s beispielsweise grundsätzlich miteinander vereinbar.

Die historische Gleichsetzung von Baud mit bit/s ist deshalb nur in bestimmten Übertragungssystemen korrekt.

RS-232 – DTE, DCE und invertierte Pegellogik

RS-232 wurde für Verbindungen zwischen Datenendeinrichtung und Datenübertragungseinrichtung entwickelt, klassisch Computer und Modem. Die elektrische Signalisierung verwendet positive und negative Spannungsbereiche und ist nicht direkt mit TTL-UART-Pegeln gleichzusetzen.

Ein PC ist typischerweise DTE, ein Modem DCE. Bei dieser Paarung sind Sende- und Empfangssignale so angeordnet, dass ein normales gerades Kabel verwendet werden kann.

Wer zwei DTE-Geräte direkt verbindet, muss die Rollen elektrisch kreuzen: daraus entsteht das Nullmodem.

DB25 und DE-9 – gleiche Funktionswelt, andere Pins

Frühe PCs und Terminals verwenden häufig 25-polige RS-232-Anschlüsse. Später setzte sich am PC ein 9-poliger serieller Anschluss durch, der nur die üblichen Signale herausführt.

Die umgangssprachliche Bezeichnung „DB9“ ist weit verbreitet; geometrisch gehört der 9-polige Steckverbinder zur DE-Größe.

Für historische Kabel ist die Pinbelegung wichtiger als der Name. Gerade Nullmodem- und Modemkabel können äußerlich identisch aussehen und intern völlig anders verdrahtet sein.

TxD, RxD und Signal Ground – die minimale Datenverbindung

Für eine einfache dreidrähtige Verbindung genügen Sendedaten, Empfangsdaten und gemeinsame Signalmasse. TxD der einen Seite wird mit RxD der anderen verbunden.

Ohne Hardwareflusskontrolle muss Software sicherstellen, dass der Empfänger den Datenstrom schnell genug verarbeitet.

Viele historische Transfers funktionieren damit zuverlässig bei moderaten Geschwindigkeiten, solange beide Seiten passend konfiguriert sind.

Nullmodem – zwei DTE-Geräte ohne echtes Modem verbinden

Ein Nullmodemkabel kreuzt die Datenrichtungen und bildet bei Bedarf auch Modem-Handshakeleitungen so nach, dass beide Endgeräte eine plausible Gegenstelle sehen.

Es existiert deshalb nicht genau eine universelle Nullmodemverdrahtung. Dreiadrige Varianten übertragen nur Daten, komplexere Kabel kreuzen RTS/CTS und DTR/DSR beziehungsweise DCD.

Für Archivdokumentation sollte die tatsächlich verwendete Verdrahtung notiert werden, statt nur „Nullmodem“ zu schreiben.

Prinzip einer einfachen Nullmodemverbindung:

DTE A                 DTE B
TxD  ----------------> RxD
RxD  <----------------  TxD
GND  -----------------  GND

Für Hardware-Handshake kommen gekreuzte bzw. passend gebrückte
RTS/CTS- und DTR/DSR/DCD-Signale hinzu.

RTS/CTS – Hardwareflusskontrolle

Request to Send und Clear to Send werden in modernen DTE-DTE-Anwendungen häufig als Hardwareflusskontrolle verwendet. Ein Empfänger kann damit signalisieren, ob weitere Daten angenommen werden können.

Das verhindert Überläufe, wenn UART-Puffer oder Software kurzzeitig nicht mithalten.

Beide Seiten müssen denselben Handshake-Modus verwenden. Eine Seite mit RTS/CTS und eine Gegenseite ohne passende Leitungen kann scheinbar grundlos stehenbleiben.

DTR, DSR und DCD – Modemsteuerung als historisches Erbe

Data Terminal Ready und Data Set Ready signalisieren Betriebsbereitschaft, Data Carrier Detect den erkannten Träger eines Modems.

Bei einer direkten Nullmodemverbindung existiert kein echter Träger. Kabel oder Software müssen die erwarteten Signale deshalb passend kreuzen oder lokal brücken.

Terminalprogramme unterscheiden sich darin, ob sie DCD zwingend erwarten oder ignorieren können.

XON/XOFF – Flusskontrolle im Datenstrom

Softwareflusskontrolle verwendet Steuerzeichen, um einen Sender anzuhalten und wieder freizugeben. XOFF pausiert, XON setzt fort.

Das benötigt keine zusätzlichen Handshakeleitungen, kollidiert aber mit binären Transfers, wenn das Transferprotokoll die Steuerzeichen nicht korrekt behandelt.

Für Binärprotokolle ist deshalb entweder transparente Behandlung oder Hardwareflusskontrolle vorzuziehen.

Parität – einfache Fehlererkennung pro Zeichen

Gerade, ungerade oder andere Paritätsmodi ergänzen jedes Zeichen um ein Prüfbit. Damit lassen sich bestimmte Übertragungsfehler erkennen.

Parität korrigiert keine Daten und schützt nicht gegen alle Mehrbitfehler.

Dateitransferprotokolle verwenden deshalb zusätzlich Blockprüfsummen oder CRCs.

UART – Parallelbytes werden zu seriellen Bits

Eine UART nimmt CPU-seitig Bytes entgegen und erzeugt daraus den asynchronen seriellen Bitstrom. Beim Empfang geschieht der umgekehrte Weg.

Puffer-FIFOs reduzieren Interruptlast. Frühe PC-UARTs besaßen kleine oder keine FIFOs, spätere Bausteine konnten höhere Geschwindigkeiten stabiler bedienen.

Der UART-Typ kann deshalb bei schnellen DOS-Transfers ebenso wichtig sein wie die nominal eingestellte Baudrate.

Geschwindigkeit – nominale Baudrate und reale Nutzrate

Ein 8N1-Zeichen benötigt typischerweise zehn Bitzeiten: Startbit, acht Datenbits und Stopbit. Die Nutzdatenrate liegt damit schon ohne Protokolloverhead unter der Leitungsbitrate.

Blockheader, CRC, Bestätigungen und Wiederholungen reduzieren die effektive Dateidatenrate weiter.

Bei langen Leitungen oder alten Pegelwandlern ist eine niedrigere Baudrate häufig zuverlässiger als ein theoretisch maximaler Wert.

Terminalprogramme als universelle Transferwerkzeuge

Terminalprogramme verbinden serielle Kommunikation, Modemsteuerung, Terminalemulation und Dateiübertragungsprotokolle in einer Oberfläche.

Sie waren auf DOS, CP/M, Amiga, Atari, Unix und vielen anderen Plattformen der zentrale Weg für Dateiaustausch über Modem oder Nullmodem.

Für reine Binärdateien ist ein Protokoll vorzuziehen; einfaches Mitschneiden eines Terminalstreams kann Steuerzeichen, Zeilenenden oder Escape-Sequenzen enthalten.

XMODEM – 128-Byte-Blöcke und Stop-and-Wait

XMODEM teilt eine Datei in kleine Datenblöcke. Nach jedem Block bestätigt der Empfänger korrektes Ankommen oder fordert eine Wiederholung an.

Frühe Varianten verwendeten eine einfache Prüfsumme, spätere XMODEM-CRC-Versionen eine 16-Bit-CRC. Das verbessert Fehlererkennung deutlich.

Das Stop-and-Wait-Verfahren ist robust, aber auf Leitungen mit hoher Verzögerung ineffizient.

XMODEM-1K – größere Blöcke

XMODEM-1K erhöht die Blockgröße auf 1024 Byte. Dadurch sinkt der relative Protokolloverhead bei zuverlässigen Leitungen.

Bei einer gestörten Verbindung muss im Fehlerfall allerdings ein größerer Block erneut übertragen werden.

Viele Terminalprogramme kombinieren 1K-Blöcke mit CRC.

YMODEM – Dateiname, Größe und Batch-Transfer

YMODEM erweitert die XMODEM-Idee um Metadatenblöcke mit Dateiname und häufig Dateigröße. Mehrere Dateien können in einer Sitzung übertragen werden.

Der Empfänger muss nicht mehr für jede Datei manuell einen Zielnamen erhalten.

Bezeichnungen wurden historisch nicht von jeder Software identisch verwendet; konkrete Implementierungen sollten deshalb dokumentiert werden.

ZMODEM – Streaming, Resume und gute Leitungsnutzung

ZMODEM wurde für schnellere und robustere Übertragung über Modems und serielle Leitungen entwickelt. Es kann mehrere Blöcke senden, ohne nach jedem einzelnen auf eine Bestätigung zu warten.

Unterbrochene Transfers können je nach Implementierung an bekannter Dateiposition fortgesetzt werden. Das war bei langen Modemübertragungen ein großer Vorteil.

Automatische Transfererkennung machte ZMODEM in vielen BBS- und Terminalumgebungen besonders komfortabel.

Kermit – Portabilität zwischen sehr unterschiedlichen Systemen

Kermit wurde für Dateiübertragung und Terminalkommunikation zwischen heterogenen Computern entwickelt. Es konnte auf Mainframes, Minicomputern, PCs und Mikrocomputern eingesetzt werden.

Die Protokollfamilie unterstützt Paketierung, Fehlerprüfung, Wiederholung und verschiedene Zeichen- beziehungsweise Dateikonventionen.

Gerade Cross-Platform-Übertragungen profitierten davon, dass nicht nur eine bestimmte PC-Modemwelt im Mittelpunkt stand.

Textmodus und Binärmodus – eine historische Fehlerquelle

Ein Texttransfer kann Zeilenenden oder Zeichendarstellung an das Zielsystem anpassen. Das ist für echte Textdateien nützlich, verändert aber Bytefolgen.

Ein Binärtransfer muss jedes Byte unverändert übertragen. Programme, Archive, Diskimages und komprimierte Dateien gehören grundsätzlich in diese Kategorie.

Viele beschädigte historische Transfers entstanden durch versehentlich aktivierte Textkonvertierung.

CRLF, LF und CR – Zeilenenden zwischen Plattformen

DOS und Windows verwenden traditionell CRLF, Unix-artige Systeme LF. Klassische Macintosh-Systeme verwendeten lange Zeit CR.

Bei Textaustausch kann eine kontrollierte Konvertierung sinnvoll sein. Bei Quellcode muss sie reproduzierbar und dokumentiert erfolgen.

Für binäre Masterdateien dürfen Zeilenendentransformationen niemals angewendet werden.

Parallelport – mehrere Datenleitungen gleichzeitig

Der klassische PC-Druckerport überträgt mehrere Datenbits parallel und ergänzt Steuer- und Statusleitungen. Ursprünglich war er primär als Ausgabe zum Drucker gedacht.

Spätere Betriebsarten ermöglichten bidirektionale Kommunikation und höhere Datenraten.

Damit wurde der Druckerport auch für Dateitransfer, Netzwerkadapter, Scanner, ZIP-Laufwerke und Dongles genutzt.

Centronics-Handshaking

Die klassische Druckerschnittstelle verwendet Datenleitungen plus Strobe-, Busy- und Acknowledge-Signale. Der Sender legt Daten an und signalisiert ihre Gültigkeit.

Obwohl die elektrische und mechanische Welt je nach PC-Stecker und Druckeranschluss variiert, prägte dieses Handshake-Modell den Parallelport lange.

Für Dateitransfer zwischen zwei PCs werden die Leitungen anders genutzt als bei einem normalen Druckerkabel.

IEEE 1284 – bidirektionale Betriebsarten

IEEE 1284 standardisierte verschiedene Betriebsarten des Parallelports. Dazu gehören Compatibility, Nibble, Byte, EPP und ECP.

EPP und ECP wurden für schnellere bidirektionale Peripherie entwickelt und unterstützen effizientere Handshakes beziehungsweise DMA-nahe Übertragung.

Mainboard-BIOSse boten deshalb häufig Auswahlmöglichkeiten für SPP, EPP oder ECP.

LapLink-Kabel – PCs direkt über Parallelport koppeln

Direkte Paralleltransferkabel kreuzen Daten- und Statusleitungen so, dass zwei PCs miteinander kommunizieren können. Bekannte Transferprogramme machten daraus eine frühe praktische PC-zu-PC-Verbindung.

Die Verdrahtung unterscheidet sich von einem normalen Druckerkabel. Eine falsche Kabelannahme führt daher nicht einfach nur zu geringerer Geschwindigkeit, sondern häufig zu gar keiner Kommunikation.

Paralleltransfer war deutlich schneller als viele serielle Nullmodemverbindungen und benötigte keine Netzwerkkarten.

PLIP – IP-Pakete über Parallelport

Parallel Line Internet Protocol nutzt einen Parallelport-Link als Netzwerkstrecke. Statt Dateien direkt zu übertragen, entsteht eine IP-Verbindung.

Darüber können dann FTP, Telnet oder andere Netzwerkprotokolle laufen.

PLIP zeigt anschaulich die Schichtung: derselbe Parallelport kann proprietären Dateitransfer oder einen vollständigen Netzwerkpfad tragen.

SLIP und PPP – IP über serielle Leitungen

SLIP kapselt IP-Pakete sehr einfach in einen seriellen Datenstrom. Es besitzt selbst wenig Aushandlung oder Fehlerkontrolle.

PPP ist umfassender und standardisiert Link Control, Aushandlung und die Einbettung verschiedener Netzwerkprotokolle.

Mit SLIP oder PPP wird aus dem Nullmodem- oder Modemlink eine IP-Verbindung; Dateiübertragung kann anschließend über normale Netzwerkprotokolle erfolgen.

Modemtransfer – Dateiaustausch über das Telefonnetz

Ein Modem wandelt digitale Daten in Signale für die Telefonleitung und zurück. Fehlerkorrektur und Datenkompression können teilweise bereits im Modem stattfinden.

Darüber laufen Terminalverbindungen und Protokolle wie XMODEM, ZMODEM oder Kermit. Später tragen Modems komplette PPP-Internetverbindungen.

Die historische DFÜ-Seite wird auf modems-und-dataphon.htm und modems-mailboxen-und-protokolle.htm vertieft.

Mailboxen – Upload und Download als Alltagskultur

BBS-Systeme verbanden Nachrichtenbereiche, Benutzerkonten und Dateibibliotheken. Upload und Download gehörten zu den zentralen Nutzungsformen.

Transferprotokolle mussten auf Telefonleitungen mit Rauschen, Verbindungsabbrüchen und begrenzter Geschwindigkeit zuverlässig arbeiten.

Die BBS-Geschichte steht auf mailboxen-bbs.htm und bulletin-board-alltag.htm.

FidoNet – Dateien und Nachrichten zwischen Systemen weiterreichen

FidoNet übertrug Nachrichtenpakete und Dateien zwischen Mailboxsystemen oft zeitgesteuert über Telefonverbindungen.

Dateiaustausch wird hier Teil eines Store-and-Forward-Netzes: Daten müssen nicht in einer einzigen End-to-End-Sitzung vom ursprünglichen Absender zum Leser laufen.

Die eigene Vertiefung liegt auf fido-und-mailbox-netze.htm.

Sneakernet – die Diskette als physischer Netzwerkträger

Beim klassischen Diskettenaustausch wird nicht die Leitung, sondern das Medium bewegt. Das kann trotz scherzhafter Bezeichnung sehr effizient sein, wenn Netzwerkhardware fehlt.

Entscheidend ist, ob Zielrechner Laufwerk, physisches Format und Dateisystem lesen kann.

Ein identischer Diskettendurchmesser bedeutet keine Kompatibilität. Spurdichte, Seitenzahl, Codierung, Sektorformat und Dateisystem können vollständig verschieden sein.

5,25-Zoll-Disketten – gleiche Hülle, viele unvereinbare Formate

5,25-Zoll-Medien wurden von Commodore, Apple, Atari, CP/M-Systemen und PCs verwendet. Laufwerksmechanik, Drehzahl, Codierung und Format unterscheiden sich.

Ein PC-Laufwerk kann beispielsweise eine Commodore-1541-Diskette nicht allein deshalb lesen, weil die Diskette mechanisch hineinpasst.

Für Cross-Platform-Austausch waren spezielle Controller, Transferkabel oder eine Zwischenplattform nötig.

3,5-Zoll-Disketten – ebenfalls keine automatische Kompatibilität

3,5-Zoll-Disketten standardisieren die mechanische Cartridge stärker, aber Dateisystem und Controllerformat bleiben plattformabhängig.

PC-DOS/FAT, AmigaDOS, Atari ST und Macintosh können dieselben Mediengrößen unterschiedlich strukturieren.

High-Density- und Double-Density-Medien bringen zusätzlich andere magnetische Anforderungen und Kapazitäten.

FAT als historische Austauschbrücke

FAT12 auf Disketten und später FAT16/FAT32 auf Wechselmedien wurde durch die große PC-Verbreitung zu einer häufigen Austauschbasis.

Viele andere Systeme erhielten Treiber oder Tools, um PC-formatierte Medien zu lesen.

FAT bewahrt jedoch keine POSIX-Rechte, Resource Forks oder viele plattformspezifische Metadaten. Als gemeinsame Schnittmenge ist das zugleich Stärke und Grenze.

CP/M – gleiche Betriebssystemfamilie, verschiedene Diskettenformate

CP/M definiert logische Dateiverwaltung, aber historische Hersteller legten Spuren, Sektoren, Skew und Blockgrößen sehr unterschiedlich fest.

Eine CP/M-Diskette ist deshalb nicht allein durch die Aufschrift „CP/M“ eindeutig lesbar.

Transferprogramme benötigen das konkrete Disk Parameter Block beziehungsweise die passende Formatdefinition.

Amiga und PC – DOS-Disketten als Brücke

AmigaDOS verwendet eigene OFS-/FFS-Dateisysteme, kann mit passenden Systemkomponenten aber PC-formatierte FAT-Disketten lesen und schreiben.

Damit entstand eine praktische Brücke zu DOS- und Windows-Rechnern, obwohl native Amiga-Disketten auf Standard-PC-Floppycontrollern nicht ohne Weiteres lesbar sind.

Archive und Binärdateien wurden häufig auf ein gemeinsames FAT-Medium gelegt, um plattformspezifische Dateisystemgrenzen zu umgehen.

Atari ST und PC – teilweise nahe Diskettenwelten

Atari-ST-Disketten verwenden FAT-artige Strukturen und MFM-Floppytechnik, wodurch der Austausch mit PCs oft einfacher war als bei Amiga oder Commodore 1541.

Trotzdem können Geometrie, Bootsektorwerte und Formatierungsvarianten Unterschiede erzeugen.

Bei archivwürdigen Medien sollte nicht angenommen werden, dass jede ST-Diskette auf jedem PC-Laufwerk vollständig identisch gelesen wird.

C64-Disketten auf moderne Systeme übertragen

1541-Disketten verwenden GCR-Codierung und eine Laufwerksarchitektur, die von Standard-PC-Floppycontrollern stark abweicht.

Historisch entstanden deshalb spezielle Kabel und Adapter zwischen Commodore-Laufwerk und PC sowie später USB-Lösungen und Fluxreader.

Ein D64-Image bewahrt die logischen Sektoren einer normalen 1541-Diskette; komplexer Kopierschutz kann tiefere Formate erfordern.

Diskimages statt Einzeldateien

Ein vollständiges Diskimage erhält Bootsektor, Dateisystem, gelöschte Bereiche und die Dateianordnung stärker als eine einfache Dateikopie.

Für Dateiaustausch reicht oft die Extraktion einzelner Dateien; für Archivierung ist zusätzlich das Gesamtimage wertvoll.

Die ausführliche Preservation-Seite steht auf emulation-und-digitaler-erhalt.htm.

Archive als plattformneutrale Transporthülle

ZIP, TAR und andere Archivformate bündeln viele Dateien zu einem Transferobjekt. Dadurch bleiben Verzeichnisstruktur und je nach Format zusätzliche Metadaten zusammen.

Das reduziert Probleme mit Zwischenmedien, die bestimmte Dateinamen oder Attribute nicht unterstützen.

Das Archivformat muss jedoch selbst die benötigten Metadaten abbilden; ZIP und TAR haben unterschiedliche historische Stärken.

Kompression spart Leitung, kostet aber Rechenzeit

Auf langsamen Modem- oder seriellen Verbindungen konnte Kompression die Übertragungszeit drastisch reduzieren, wenn Dateien stark komprimierbar waren.

Bereits komprimierte Bilder, Archive oder moderne Medienformate profitieren dagegen kaum und können durch zusätzliche Verpackung sogar größer werden.

Für historische Systeme musste außerdem berücksichtigt werden, ob genug RAM und CPU-Leistung zum Entpacken vorhanden waren.

Große Dateien auf kleine Medien aufteilen

Wenn eine Datei größer als eine Diskette oder ein Dateisystemlimit ist, kann sie in mehrere Teile zerlegt und auf dem Ziel wieder zusammengesetzt werden.

Teilnummerierung, Dateigröße und Prüfsumme müssen eindeutig sein.

Diese Technik war bei Disketten, frühen Mailboxen und Größenlimits von Mailanhängen verbreitet und bleibt auch bei heutigen Uploadlimits grundsätzlich nutzbar.

Dateinamen – 8.3 trifft lange Unicode-Namen

DOS-8.3-Namen, Amiga-, Unix-, Macintosh- und moderne Windows-Namensregeln unterscheiden sich bei Länge, erlaubten Zeichen und Groß-/Kleinschreibung.

Ein Transfer auf ein restriktiveres Dateisystem kann Namen kürzen oder verändern.

Für archivwürdige Bestände sollten Originalnamen entweder im Container erhalten oder in Metadaten festgehalten werden.

Groß-/Kleinschreibung – README und readme können zwei Dateien sein

POSIX-Dateisysteme behandeln Groß- und Kleinschreibung häufig als verschieden. Windows-Standarddateisysteme bewahren die Schreibweise, vergleichen Namen jedoch typischerweise ohne Groß-/Kleinschreibung.

Beim Kopieren zweier unterschiedlich geschriebener Dateien auf ein case-insensitives Ziel kann eine Kollision entstehen.

Archivwerkzeuge sollten solche Konflikte melden statt still eine Datei zu überschreiben.

Reservierte Namen und ungültige Zeichen

Zeichen wie Doppelpunkt, Backslash oder Schrägstrich haben je nach Plattform besondere Bedeutung. Windows reserviert zusätzlich historische Gerätenamen.

Ein Dateiname, der auf Unix problemlos existiert, kann auf einem anderen Ziel nicht direkt angelegt werden.

Eine reversible Namensabbildung ist für Cross-Platform-Archive besser als spontane manuelle Umbenennung.

Zeitstempel – Auflösung, Zeitzone und Semantik

Dateisysteme unterscheiden zwischen Änderungs-, Zugriffs-, Erstellungs- und Metadatenzeiten. Nicht jedes System besitzt alle diese Zeittypen.

Auflösung reicht historisch von zwei Sekunden bei klassischen FAT-Zeiten bis zu sehr feinen modernen Zeitstempeln.

Beim Transfer können Zeitzonen und Sommerzeitinterpretationen zusätzlich zu scheinbaren Datumsverschiebungen führen.

Dateirechte und ausführbare Bits

POSIX-Rechte, Windows-ACLs und klassische Heimcomputerattribute lassen sich nicht verlustfrei ineinander abbilden.

Eine Datei kann ihren Inhalt unverändert behalten und trotzdem auf dem Ziel nicht mehr ausführbar oder anders geschützt sein.

Archivcontainer oder Metadatenmanifest können solche Eigenschaften separat sichern.

Symbolische Links und Verknüpfungen

Ein symbolischer Link ist kein normaler Dateikopiedatensatz, sondern ein Verweis auf einen Pfad. Transferprogramme müssen entscheiden, ob sie den Link selbst oder sein Ziel kopieren.

Auf Plattformen ohne entsprechendes Konzept kann die Semantik verloren gehen.

Gerade rsync, tar und Unix-Dateifreigaben unterscheiden deshalb explizit zwischen Link und referenziertem Inhalt.

Resource Forks und plattformspezifische Zusatzdaten

Klassische Macintosh-Dateien können Daten- und Resource Fork getrennt speichern. Eine reine Kopie des Data Fork verliert dann Programmressourcen, Icons oder Metadaten.

AppleDouble- und Archivformate entstanden unter anderem, um solche Zusatzdaten auf fremden Dateisystemen transportieren zu können.

Ähnliche Probleme existieren mit NTFS Alternate Data Streams und erweiterten POSIX-Attributen.

Extended Attributes und Alternate Data Streams

Moderne Dateisysteme können zusätzliche Schlüssel-Wert-Metadaten oder benannte Streams an Dateien hängen.

Ein einfaches FTP- oder FAT-Zwischenmedium überträgt diese Informationen typischerweise nicht.

Bei Systemmigration muss deshalb entschieden werden, ob nur Dateiinhalte oder vollständige Dateisystemsemantik erhalten werden soll.

ASCII, PETSCII, ATASCII, Codepages und Unicode

Dateiinhalte und Dateinamen wurden historisch in sehr unterschiedlichen Zeichensätzen gespeichert. Ein Bytewert repräsentiert deshalb nicht überall denselben Buchstaben.

Textübertragung kann Zeichen konvertieren, wenn Quell- und Zielkodierung bekannt sind. Binärübertragung bewahrt dagegen die Bytes unverändert.

Für Archiverhalt ist die originale Kodierung plus dokumentierte Interpretation meist besser als eine unprotokollierte Konvertierung.

Endianess betrifft Binärformate, nicht das bloße Kopieren

Eine Datei bleibt beim korrekten Binärtransfer byteidentisch, unabhängig davon, ob Quell- und Zielprozessor little-endian oder big-endian sind.

Erst wenn das Zielprogramm Mehrbytewerte interpretiert, spielt Byteorder eine Rolle.

Ein Transferprogramm darf Binärdateien deshalb nicht aufgrund der Prozessorarchitektur automatisch umordnen.

Wechselmedien von SyQuest bis ZIP und MO

Wechselplatten, ZIP-, Jaz-, SyQuest- und magneto-optische Medien boten deutlich größere Kapazitäten als Disketten und wurden wichtige Austauschmedien.

Die Hürde verschiebt sich dabei vom Dateiformat zum verfügbaren Laufwerk und Interface: SCSI, Parallelport, IDE oder proprietäre Varianten.

Die SyQuest-Vertiefung liegt auf syquest.htm.

SCSI – mehrere Betriebssysteme, gemeinsamer Blockspeicher

SCSI standardisiert Gerätekommunikation auf Block- und Kommandobasis. Dasselbe Laufwerk kann prinzipiell an unterschiedlichen Rechnerplattformen betrieben werden.

Das Dateisystem auf dem Medium bleibt davon unabhängig. Ein Amiga-SCSI-Laufwerk mit AmigaDOS-Partitionen wird auf einem PC nicht allein durch den SCSI-Anschluss verständlich.

Gerätegeometrie, Partitionstabellen und Dateisystemtreiber sind eigene Ebenen.

IDE/ATA und CompactFlash als praktische Brücke

CompactFlash kann einen ATA-kompatiblen Modus bereitstellen und wurde deshalb häufig als Ersatz oder Transfermedium für ältere IDE-Systeme eingesetzt.

Ein Kartenleser am modernen Rechner ermöglicht direkten Zugriff auf das Medium, sofern Partitionierung und Dateisystem verstanden werden.

Für historische Systeme ist dabei auf Größenlimits, CHS/LBA-Verhalten und Stromversorgung zu achten.

SD-Karten in Retro-Adaptern

Moderne Adapter präsentieren SD-Karten historischen Rechnern als Diskettenlaufwerk, Festplatte oder proprietäres Massenspeichergerät.

Der Transfer zum modernen Rechner wird dadurch bequem, weil die SD-Karte direkt gelesen werden kann.

Das Adapter-Dateiformat kann jedoch Diskimages statt normaler Dateien enthalten; die SD-Karte ist dann nur Träger einer zweiten Speicherschicht.

Ethernet – aus Punkt-zu-Punkt-Transfer wird ein Netz

Ethernet transportiert Frames zwischen Netzwerkschnittstellen. Dateiaustausch entsteht erst durch darüberliegende Protokolle.

TCP/IP machte heterogene Rechnernetze besonders flexibel, weil dieselben Transport- und Anwendungsprotokolle über verschiedene Ethernetgenerationen und andere Links laufen können.

Die Netzwerktechnik wird auf netzwerk-und-heimvernetzung.htm vertieft.

TCP – zuverlässiger Bytestrom

TCP stellt Anwendungen einen geordneten, zuverlässigen Bytestrom bereit. Sequenznummern, Bestätigungen, Wiederübertragungen und Flusskontrolle verbergen Paketverlust weitgehend vor dem Dateiprotokoll.

TCP kennt selbst keine Dateinamen oder Verzeichnisse. FTP, SSH, HTTP und viele andere Protokolle bauen darauf eigene Semantik.

Die heutige konsolidierte TCP-Spezifikation ist RFC 9293.

UDP – Datagramme ohne eingebaute Zuverlässigkeit

UDP überträgt einzelne Datagramme, ohne Verbindung, Reihenfolge oder Wiederholung auf Transportebene zu garantieren.

Anwendungen können eigene Zuverlässigkeit darüber bauen oder bewusst auf geringe Latenz setzen.

TFTP ist ein klassisches Beispiel eines einfachen Dateitransfers auf UDP-Basis.

FTP – der klassische Internet-Dateitransfer

FTP verwendet getrennte Steuer- und Datenverbindungen. Der Client sendet Kommandos wie Login, Verzeichniswechsel, Dateiabruf und Upload über die Steuerverbindung.

RFC 959 definiert verschiedene Repräsentationstypen, darunter ASCII und Image/Binary. Gerade diese Trennung erklärt historische Textmodusprobleme.

Klassisches FTP bietet keine moderne Vertraulichkeit für Zugangsdaten und Dateiinhalte und sollte über unsichere Netze nicht als Sicherheitslösung betrachtet werden.

Aktives und passives FTP

Beim aktiven FTP öffnet die Serverseite die Datenverbindung zum vom Client gemeldeten Port. Firewalls und NAT erschweren dieses Modell.

Im passiven Modus öffnet der Server einen Datenport und der Client verbindet sich dorthin. Das ist in modernen Netzen meist einfacher.

Die getrennten FTP-Verbindungen bleiben trotzdem ein Sonderfall gegenüber Protokollen, die alles in einer einzigen verschlüsselten Sitzung tragen.

FTP ASCII und Image – historisch wichtig, heute leicht übersehen

Der ASCII-Modus kann Textrepräsentationen zwischen unterschiedlichen Hostsystemen anpassen. Image Type überträgt einen kontinuierlichen Bytestrom unverändert.

Für Archive, Programme, Bilder und praktisch alle modernen Binärformate ist Image/Binary die sichere Wahl.

Automatische Moduserkennung klassischer Clients konnte bei ungewöhnlichen Dateiendungen gefährlich sein.

Fortsetzen unterbrochener FTP-Transfers

FTP-Erweiterungen und verbreitete Clients erlauben das Wiederaufsetzen an einer Dateiposition. Das spart bei großen Dateien Zeit.

Resume setzt voraus, dass die teilweise vorhandene Zieldatei tatsächlich zum selben Quellobjekt gehört.

Ein abschließender Hash ist deshalb wichtiger als die bloße Meldung, dass ein Transfer fortgesetzt wurde.

FTPS – FTP über TLS

FTPS erweitert FTP um TLS-Schutz für Authentifizierung und Datenkanäle. Es bleibt jedoch strukturell FTP mit seinen getrennten Kontroll- und Datenverbindungen.

FTPS ist nicht dasselbe wie SFTP. Die ähnliche Bezeichnung führt häufig zu falscher Konfiguration.

Firewall- und Zertifikatsmanagement unterscheiden sich deutlich von SSH-basierten Transfers.

TFTP – bewusst kleines Dateiprotokoll

Trivial File Transfer Protocol verwendet UDP und einen sehr kleinen Funktionsumfang. Historisch und bis heute wird es vor allem für Boot-, Firmware- und Gerätebereitstellung in kontrollierten Netzen eingesetzt.

TFTP besitzt keine normale Verzeichnisnavigation und keine eingebaute moderne Benutzerauthentifizierung.

Es ist deshalb ein spezialisiertes Infrastrukturwerkzeug, kein allgemeiner Ersatz für SFTP oder HTTPS.

SSH – sicherer Transport für entfernte Dienste

SSH stellt Verschlüsselung, Integrität und Serverauthentisierung für Remote-Dienste bereit. Die Transportebene läuft typischerweise über TCP.

Darauf bauen Remote-Shells, Portweiterleitung und Dateitransfermechanismen.

RFC 4253 beschreibt den SSH-Transportlayer; konkrete sichere Dateitransfers können darauf unterschiedlich realisiert werden.

SFTP – Dateiverwaltung als SSH-Subsystem

SFTP ist ein eigenes Dateitransfer- und Dateiverwaltungsprotokoll über SSH. Es ist nicht „FTP mit SSH-Verschlüsselung“.

Es bietet Operationen für Dateien, Verzeichnisse, Attribute und Positionszugriffe innerhalb einer einzigen SSH-geschützten Sitzung.

Die verbreitete Protokollfamilie stammt aus SSH-File-Transfer-Entwürfen und Implementierungspraxis; die konkrete unterstützte Version hängt von Client und Server ab.

SCP – Datei kopieren über SSH

SCP ist historisch ein einfaches Werkzeug für Remote-Kopien über SSH. Moderne OpenSSH-Versionen können für scp-Kommandos intern SFTP verwenden, um ältere Protokollprobleme zu vermeiden.

Die gewohnte Quell-/Zielsyntax bleibt dadurch ähnlich, während das Übertragungsprotokoll im Hintergrund variieren kann.

Für reproduzierbare Systemdokumentation ist deshalb die Toolversion relevant.

rsync – nur Unterschiede übertragen

rsync vergleicht Dateibestände und kann bei geeigneten Bedingungen nur geänderte Daten übertragen. Das spart Bandbreite bei großen ähnlichen Dateien oder Verzeichnisbäumen.

Es kann lokale Pfade, Remote-Shell-Transporte und einen eigenen Daemonmodus nutzen.

Optionen entscheiden, ob Zeiten, Rechte, Links, ACLs und Extended Attributes erhalten werden. „rsync verwendet“ sagt daher allein noch nicht, welche Dateisemantik bewahrt wurde.

Synchronisieren und Spiegeln sind nicht dasselbe wie Backup

Mit Löschoptionen kann rsync Zielobjekte entfernen, die an der Quelle nicht mehr vorhanden sind. Das ist für einen Spiegel korrekt und für ein Archiv potenziell gefährlich.

Eine beschädigte oder versehentlich geleerte Quelle kann dadurch auch ein Ziel leeren.

Versionierte Backups und unveränderliche Archivkopien müssen deshalb getrennt von Synchronisationsjobs geplant werden.

SMB – Dateifreigaben in Windows- und heterogenen Netzen

Server Message Block bietet entfernte Dateien, Verzeichnisse, Drucker und weitere Ressourcen mit Netzwerkdateisystemsemantik.

SMB überträgt nicht nur Dateiinhalt, sondern auch Operationen, Locks und Metadaten. Moderne Implementierungen unterstützen Authentisierung, Signierung und je nach Version Verschlüsselung.

Samba ermöglicht SMB-Zugriff zwischen Unix-artigen und Windows-Systemen, wobei Rechte- und Namensabbildungen konfiguriert werden müssen.

NFS – entfernte Unix-Dateibäume

Network File System bindet entfernte Verzeichnisse so ein, dass Anwendungen sie weitgehend wie lokale Dateisysteme verwenden.

UID/GID, Rechte, Locks und Cacheverhalten sind wichtiger als bei einem simplen Upload/Download-Protokoll.

Für heterogene Umgebungen muss geklärt sein, wie Identitäten und Dateinamen zwischen Server und Client abgebildet werden.

WebDAV – HTTP um Dateiverwaltung erweitern

WebDAV ergänzt HTTP um Methoden und Eigenschaften für entfernte Ressourcen, Sammlungen und bestimmte Metadatenoperationen.

Dadurch können Server Dateibäume über eine webnahe Infrastruktur bereitstellen.

WebDAV ist stärker dateiverwaltungsorientiert als ein einfacher HTTP-Download, bleibt aber von Server- und Clientimplementierung abhängig.

HTTP/HTTPS – heute einer der universellsten Downloadwege

HTTP überträgt Ressourcen und unterstützt unter anderem Bereichsanfragen, Caching und Metadatenheader. HTTPS schützt den Transport zusätzlich durch TLS.

Browser, Paketmanager, Updateprogramme und APIs nutzen dieselbe Protokollfamilie für sehr unterschiedliche Datei- und Objektransfers.

Ein HTTP-Download bewahrt jedoch keine lokalen Dateirechte oder Dateisystemattribute, sofern diese nicht separat kodiert sind.

Range Requests – Teile großer Dateien gezielt abrufen

HTTP kann Bereiche einer Ressource anfordern. Downloader nutzen das für Resume oder parallele Teiltransfers, sofern der Server dies unterstützt.

Teilbereiche müssen am Ende wieder exakt zur erwarteten Gesamtdatei zusammengesetzt werden.

ETag, Last-Modified und eigene Hashwerte helfen, eine Fortsetzung nicht versehentlich mit einer inzwischen veränderten Quelldatei zu vermischen.

Object Storage – Dateien werden zu Objekten mit Schlüssel und Metadaten

Cloud-Object-Storage organisiert Daten nicht wie ein klassisches gemountetes Dateisystem, sondern als Objekte in Buckets beziehungsweise Namespaces.

Objektname, Metadaten, Versionierung und Zugriffspolitik ersetzen Teile klassischer Dateisystemsemantik.

Clients können Objekte über HTTPS-APIs hoch- und herunterladen; lokale Rechte, Hardlinks oder Verzeichnisse müssen gegebenenfalls separat abgebildet werden.

Cloud-Synchronisation – bequem, aber semantisch ein Replikationssystem

Synchronisationsdienste beobachten lokale Änderungen und gleichen sie mit Cloud- und anderen Clientzuständen ab.

Konflikte, Löschungen und Umbenennungen werden nach Dienstlogik repliziert. Das ist etwas anderes als ein unveränderliches Archiv.

Für wichtige Bestände sollten lokale unabhängige Backups bestehen, auch wenn Cloud-Sync den Alltagstransfer übernimmt.

Peer-to-Peer-Synchronisation

Peer-Synchronisationssysteme übertragen Verzeichnisse direkt zwischen autorisierten Geräten, ohne dass jede Datei dauerhaft auf einem zentralen Cloudserver liegen muss.

Hashbasierte Blockvergleiche und Versionsinformationen können effiziente Aktualisierungen ermöglichen.

Auch hier gilt: Synchronisation repliziert Zustände und ersetzt keine bewusst versionierte Archivstrategie.

USB – Bus und Protokollfamilie, nicht automatisch Dateiaustausch

USB verbindet Host und Geräte über standardisierte elektrische und protokolltechnische Ebenen. Welche Datenfunktion entsteht, bestimmt die Geräteklasse beziehungsweise das darüber laufende Protokoll.

Ein USB-C-Stecker kann je nach Gerät und Kabel sehr unterschiedliche Datenraten und Funktionen tragen.

Für Dateiaustausch sind Mass Storage, MTP/PTP, Netzwerkadapter oder herstellerspezifische Protokolle relevant – nicht die Steckerform allein.

USB4 Version 2.0 – moderner Hochgeschwindigkeitslink

USB4 Version 2.0 ist 2026 die aktuelle USB4-Spezifikationsgeneration. Sie erweitert die mögliche Linkleistung deutlich gegenüber frühen USB4-Ausbaustufen.

Das ist eine Transport- und Tunnelingarchitektur. Ob Dateien als Mass-Storage-Blöcke, über ein Netzwerk oder über ein Geräteprotokoll fließen, wird auf höheren Ebenen entschieden.

Hohe Linkbandbreite garantiert deshalb weder hohe Laufwerksgeschwindigkeit noch gute Dateitransferraten, wenn Speichergerät, Controller oder Protokoll limitieren.

USB Mass Storage – Blockgerät statt Datei-API

USB-Mass-Storage präsentiert dem Host einen blockorientierten Datenträger. Das Betriebssystem liest Partitionstabelle und Dateisystem wie bei einer lokalen Platte.

Der USB-Standard transportiert also Blöcke; FAT, exFAT, NTFS, ext4 oder andere Dateisysteme bestimmen die Dateien.

Das macht USB-Sticks zu universellen Austauschmedien, sofern beide Plattformen dasselbe Dateisystem verstehen.

USB Attached SCSI – effizientere Mass-Storage-Kommandos

UAS transportiert SCSI-Kommandos über USB und erlaubt gegenüber älteren Bulk-Only-Transportmodellen bessere Parallelität und Command Queuing.

Bei SSDs und schnellen Gehäusen kann das die Effizienz deutlich verbessern.

Auch hier bleibt das Dateisystem oberhalb des Blocktransports eine separate Schicht.

MTP – Dateien statt Rohblöcke

Media Transfer Protocol präsentiert dem Host Objekte und Metadaten statt eines direkt gemounteten Blockgeräts.

Das Gerät behält Kontrolle über sein internes Dateisystem. Dadurch kann es gleichzeitig eigene Datenbanken und Speicherverwaltung konsistent halten.

MTP eignet sich für Telefone und Mediengeräte, verhält sich aber nicht wie ein klassisches Laufwerk mit beliebigen Dateisystemoperationen.

PTP – Kameraobjekte übertragen

Picture Transfer Protocol wurde für den Austausch von Bildern und verwandten Objekten mit Kameras entwickelt.

MTP baut konzeptionell auf dieser Objekttransferwelt auf und erweitert sie für Mediengeräte.

Aus Benutzersicht erscheinen Bilder und Dateien, technisch existiert aber kein frei zugängliches Blockdateisystem.

USB-Transferkabel – zwei Hosts brauchen aktive Brückenelektronik

Zwei klassische USB-Hostports werden nicht einfach mit einem passiven A-A-Kabel zu einer sicheren Dateiverbindung verbunden.

Spezielle PC-zu-PC-Transferkabel enthalten eine Brücke, die sich gegenüber beiden Rechnern als Gerät verhält und Daten kontrolliert weiterreicht.

Moderne USB-C- und Thunderbolt-/USB4-Topologien besitzen andere Rollenmechanismen, dennoch muss eine unterstützte Host-zu-Host-Funktion existieren; der Stecker allein genügt nicht.

Direktes Ethernetkabel – Auto-MDI-X vereinfacht alte Crossover-Regeln

Frühe Ethernetgeräte benötigten für eine direkte PC-zu-PC-Verbindung häufig ein Crossover-Kabel, weil Sende- und Empfangspaare sonst nicht passend verbunden waren.

Moderne Ethernetports beherrschen meist automatische MDI/MDI-X-Erkennung und kommen mit normalen Patchkabeln zurecht.

Anschließend benötigen beide Systeme passende IP-Adressen und ein Dateitransfer- oder Freigabeprotokoll.

WLAN – Netzwerktransport ohne Kabel

WLAN ersetzt die Ethernetleitung durch Funk, nicht die höheren Dateiprotokolle. SMB, SFTP, HTTP, WebDAV oder Synchronisationsdienste funktionieren darüber im Prinzip genauso wie über kabelgebundenes IP.

Funkbedingungen, Kanalbelegung und Energiesparmechanismen beeinflussen reale Datenrate und Latenz.

Für große Archivtransfers bleibt eine stabile kabelgebundene Verbindung häufig besser reproduzierbar.

Wi-Fi Direct und lokale Peer-Verbindungen

Wi-Fi-Direct-artige Verfahren ermöglichen direkte Funkgruppen zwischen Geräten ohne klassisches Infrastruktur-WLAN.

Darüber kann ein herstellerspezifischer Dateiaustauschdienst oder ein normales IP-Protokoll laufen.

Die eigentliche Dateisemantik wird wieder von der Anwendung bestimmt, nicht von der Funkverbindung.

Bluetooth – kurze Reichweite, viele Profile

Bluetooth stellt Funkverbindungen für unterschiedliche Profile bereit. Dateitransfer war historisch besonders über OBEX-basierte Profile verbreitet.

Moderne Geräte verwenden Bluetooth häufig eher für Steuerung, Authentisierung oder kleine Objekte als für sehr große Datenmengen.

Unterstützte Profile hängen von Plattform und Gerät ab; „Bluetooth vorhanden“ garantiert daher keinen generischen Dateiversand.

OBEX – Objekte über kurze Verbindungen austauschen

Object Exchange definiert ein Anfrage-/Antwortmodell für benannte Objekte und Metadaten. Es wurde unter anderem über Infrarot und Bluetooth verwendet.

Dateien werden damit als Objekte übertragen, nicht als freigegebenes entferntes Dateisystem.

Mobiltelefone der 2000er-Jahre nutzten solche Verfahren häufig für Bilder, Klingeltöne und Kontakte.

IrDA – Sichtverbindung statt Kabel

Infrarotschnittstellen verbanden Notebooks, Handhelds, Mobiltelefone und Drucker ohne physisches Kabel.

Die optische Verbindung benötigte Sichtkontakt und kurze Distanz, konnte darüber aber serielle oder objektorientierte Protokolle tragen.

IrDA war eine wichtige Übergangstechnik vor der breiten Bluetooth- und WLAN-Verfügbarkeit.

Moderne Nahbereichsfreigaben

Aktuelle Betriebssysteme kombinieren Geräteerkennung, Bluetooth, WLAN und verschlüsselte Peer-Verbindungen zu komfortablen Dateifreigaben.

Der Benutzer sieht nur einen Gerätenamen; im Hintergrund können mehrere Transportwege für Discovery und eigentliche Datenübertragung zusammenspielen.

Für Langzeitdokumentation sind solche proprietären Komfortschichten weniger transparent als ein klar beschriebenes SFTP- oder SMB-Verfahren.

E-Mail-Anhänge – Datei als Nachrichteninhalt

E-Mail war und ist ein verbreiteter Weg, kleinere Dateien zwischen organisatorisch getrennten Systemen auszutauschen.

Binärdaten werden in Internet-Mail typischerweise über MIME-Transferkodierungen in eine übertragbare Nachrichtenstruktur eingebettet.

Größenlimits, Virenscanner und serverseitige Veränderungen machen E-Mail ungeeignet für große oder bitkritische Archivtransfers ohne zusätzliche Kontrolle.

Binärdateien über textorientierte Nachrichtensysteme

Historische Netze übertrugen Binärdaten teils über textorientierte Kanäle. Kodierungen wie uuencode stellten beliebige Bytes als druckbare Zeichen dar.

Später erhöhten effizientere Kodierungen die Nutzrate.

Die Notwendigkeit solcher Verfahren zeigt, wie stark die Eigenschaften des Transportkanals das Dateiformat beeinflussen können.

uuencode – Binärdaten als ASCII-Text

uuencode bildet Binärdaten auf einen druckbaren Zeichenvorrat ab, sodass sie über Systeme transportiert werden können, die nicht für transparente 8-Bit-Daten ausgelegt sind.

Das Ergebnis wird größer als die Originaldatei, ist dafür robust gegenüber vielen textorientierten Mail- und Newswegen.

Nach der Dekodierung sollte die Binärdatei über Größe und Hash geprüft werden.

Base64 – moderner verbreitete Binär-zu-Text-Kodierung

Base64 kodiert jeweils drei Eingabebytes in vier Zeichen aus einem begrenzten Alphabet. Der Datenumfang wächst dadurch grob um ein Drittel.

MIME-E-Mail, APIs, Zertifikatsdarstellungen und viele Konfigurationsformate verwenden Base64.

Base64 ist keine Verschlüsselung und bietet allein keine Integritätsgarantie.

Remote-Dateisystem oder expliziter Transfer?

SMB und NFS lassen entfernte Dateien direkt in Anwendungen erscheinen. FTP, SFTP und HTTP kopieren dagegen typischerweise zwischen lokalen und entfernten Namensräumen.

Direktes Arbeiten auf einer Netzwerkfreigabe ist bequem, kann bei Verbindungsabbrüchen aber andere Fehlerbilder erzeugen als ein abgeschlossener Datei-Upload.

Für Archivmaster ist ein kontrollierter Kopiervorgang mit anschließender Hashprüfung häufig besser dokumentierbar.

Streaming ohne Zwischendatei

Unix-Pipelines und Netzwerktools können Daten direkt von Quelle zu Ziel streamen, ohne eine vollständige temporäre Datei anzulegen.

Das eignet sich für Images, Kompression und Backups, erhöht aber die Bedeutung sauberer Fehlerbehandlung.

Quell- und Zielhash können während beziehungsweise nach dem Stream getrennt berechnet werden.

Sparse Files – logische Größe und belegter Speicher unterscheiden sich

Sparse Files enthalten Bereiche, die logisch aus Nullen bestehen, aber auf dem Dateisystem keine physischen Blöcke belegen.

Ein naiver Transfer kann diese Löcher materialisieren und die Zieldatei wesentlich mehr Platz belegen lassen.

Werkzeuge wie rsync, tar oder spezialisierte Kopierprogramme besitzen Optionen zum Erhalt von Sparse-Strukturen.

Hardlinks – mehrere Namen, dieselben Datenblöcke

Auf unterstützenden Dateisystemen können mehrere Verzeichniseinträge auf dasselbe Dateiobjekt zeigen.

Ein einfaches Kopierprogramm erzeugt daraus mehrere unabhängige Dateien und verändert damit die Dateisystemstruktur.

Archivwerkzeuge müssen Hardlinkbeziehungen explizit erkennen, wenn deren Erhalt wichtig ist.

ACLs und Besitzinformationen

Access Control Lists beschreiben feinere Zugriffsrechte als einfache Unix-Modusbits. Windows- und POSIX-ACL-Modelle sind nicht vollständig identisch.

Ein Dateitransfer kann Inhalte korrekt kopieren und Sicherheitsinformationen verlieren.

Bei Migration ganzer Systeme muss deshalb die Rechteebene separat getestet werden.

Hashes nach dem Transfer vergleichen

SHA-256 ist für heutige Integritätsvergleiche eine robuste Standardwahl. Beide Seiten berechnen den Digest über exakt dieselben Bytes.

Stimmen die Hashes überein, ist der Dateiinhalt mit sehr hoher Sicherheit identisch. Dateiname, Rechte und Zeitstempel werden dadurch nicht geprüft.

Für vollständige Dateibaumvergleiche sind zusätzliche Metadatenmanifeste oder spezialisierte Werkzeuge sinnvoll.

CRC – hervorragend für Übertragungsfehler, kein kryptografischer Beweis

Cyclic Redundancy Checks erkennen typische Bitfehler in Blöcken sehr effizient und werden in vielen Leitungs- und Speicherprotokollen eingesetzt.

Sie sind nicht gegen absichtliche Manipulation konstruiert.

XMODEM-CRC, Ethernet-FCS und Archivprüfsummen erfüllen daher andere Aufgaben als SHA-256.

Hashmanifest für viele Dateien

Ein Manifest speichert Pfad und erwarteten Hash für einen ganzen Dateibaum. Nach Kopie oder Lagerung kann der Bestand automatisiert geprüft werden.

Pfade müssen in einer eindeutig definierten Kodierung und relativen Basis vorliegen.

Das Manifest selbst sollte zusammen mit Datum und Hashalgorithmus dokumentiert werden.

Resume sicher verwenden

Fortsetzen spart Bandbreite, wenn Quelle und partielle Zieldatei zusammengehören.

Hat sich die Quelle zwischenzeitlich geändert, kann ein blindes Resume eine syntaktisch vollständige, aber inhaltlich gemischte Datei erzeugen.

Protokolle und Tools mit Versionsprüfung beziehungsweise abschließender Hashkontrolle reduzieren dieses Risiko.

Temporärdatei und atomare Umbenennung

Robuste Transfers schreiben zunächst unter einem temporären Namen. Erst nach erfolgreicher Übertragung und gegebenenfalls Prüfung wird die Datei auf den endgültigen Namen umbenannt.

Andere Programme sehen dadurch nicht versehentlich eine halbfertige Zieldatei als vollständiges Objekt.

Auf demselben Dateisystem kann eine Umbenennung häufig atomar erfolgen.

Teilkopien klar kennzeichnen

Abgebrochene Transfers sollten als unvollständig erkennbar bleiben. Erweiterungen wie .part oder separate Arbeitsverzeichnisse sind dafür verbreitet.

Ein Zielprogramm darf eine Teilkopie nicht als Original interpretieren.

Nach erfolgreichem Abschluss kann der temporäre Zustand kontrolliert aufgelöst werden.

Transportverschlüsselung – Schutz auf dem Weg

SSH, TLS und andere sichere Transportprotokolle schützen Vertraulichkeit und Integrität gegen Beobachtung und Manipulation auf der Strecke.

Sie schützen nicht automatisch eine Datei, nachdem sie am Ziel entschlüsselt gespeichert wurde.

Ende-zu-Ende-Dateiverschlüsselung und Transportverschlüsselung sind deshalb zwei verschiedene Schutzebenen.

Authentisierung – mit welcher Gegenstelle wird gesprochen?

Sichere Dateiübertragung benötigt nicht nur Verschlüsselung, sondern auch Gewissheit über die Gegenstelle.

SSH-Hostkeys und TLS-Zertifikate lösen dieses Problem mit unterschiedlichen Vertrauensmodellen.

Warnungen über geänderte Schlüssel oder ungültige Zertifikate sollten nicht routinemäßig weggeklickt werden, weil sie genau diese Identitätsprüfung betreffen.

Passwörter und Schlüssel

SSH kann Benutzer über Passwörter oder Public-Key-Verfahren authentisieren. Automatisierte Transfers sollten Zugangsdaten nicht als Klartext in Skripten verteilen.

Private Schlüssel benötigen eigene Zugriffsrechte und gegebenenfalls Passphrasenschutz.

Dateitransferautomatisierung ist nur so sicher wie das Credential-Management dahinter.

Klassisches FTP über fremde Netze vermeiden

Normales FTP schützt Benutzername, Passwort und Dateidaten nicht durch moderne Transportverschlüsselung.

In isolierten historischen Netzen kann es für Kompatibilität weiterhin sinnvoll sein. Über öffentliche oder nicht vertrauenswürdige Netze sind SSH-basierte oder TLS-geschützte Verfahren vorzuziehen.

Historische Authentizität und heutige Netzsicherheit sollten dabei klar getrennt werden.

Alte Protokolle in isolierte Transferzonen setzen

Sehr alte Rechner unterstützen eventuell nur unsichere Netzwerkprotokolle. Statt sie direkt ins Internet zu stellen, kann ein moderner Gatewayrechner zwischen historischem und aktuellem Netz vermitteln.

Der Gateway nimmt auf der Retro-Seite das alte Protokoll an und überträgt Daten anschließend sicher weiter.

So bleibt historische Hardware nutzbar, ohne ihre Sicherheitsgrenzen auf das gesamte Netz auszudehnen.

Transfer-Gateway – eine kontrollierte Brücke zwischen Epochen

Ein Transfer-Gateway besitzt mehrere Schnittstellen oder Dateisystemtreiber und übersetzt zwischen ihnen. Beispiele sind ein PC mit serieller Schnittstelle plus Ethernet oder ein moderner Rechner mit Fluxreader und Netzspeicher.

Die Brücke sollte möglichst wenig automatisch verändern. Binärdaten bleiben binär, Dateinamenkonvertierungen werden dokumentiert und Masterimages separat gespeichert.

Für SSLXY ist diese Denkweise besonders passend: alte Systeme müssen nicht modernisiert werden, wenn eine saubere äußere Brücke genügt.

USB-zu-Seriell – moderne Rechner an historische RS-232-Geräte anbinden

USB-Seriell-Adapter stellen am Host eine virtuelle serielle Schnittstelle bereit und erzeugen über einen Pegelwandler die passende physische Signalisierung.

Nicht jeder Adapter führt alle Modemsteuerleitungen heraus oder verhält sich bei ungewöhnlichen Baudraten identisch.

Für anspruchsvolle Nullmodem- und Hardwarehandshake-Anwendungen sollte deshalb der konkrete Adapter dokumentiert und getestet werden.

Parallelport auf modernen Rechnern – USB-Druckadapter sind kein echter LPT-Ersatz

Einfache USB-Paralleladapter sind meist für Druckerprotokolle ausgelegt. Sie stellen keine frei programmierbaren klassischen LPT-Register bereit.

Alte LapLink-, Dongle- oder Bitbanging-Software funktioniert damit deshalb häufig nicht.

Für echte historische Parallelportfunktionen sind spezialisierte Hardware oder ein Rechner mit nativem beziehungsweise PCIe-basiertem Port geeigneter.

Serial Device Server – RS-232 über IP verlängern

Serielle Device Server kapseln UART-Daten und teilweise Modemsteuerleitungen in Netzwerkverbindungen.

Damit können historische Geräte räumlich entfernt an moderne Hosts angebunden werden.

Netzwerklatenz und Paketierung können jedoch zeitkritisches serielles Verhalten verändern; reine Dateiübertragung ist meist unkritischer als hardwaregenaue Protokolle.

Protokoll-Gateway – altes FTP innen, SFTP außen

Ein isoliertes Retro-Netz kann einen lokalen FTP-Server bereitstellen, weil historische Clients nichts Neueres beherrschen.

Ein moderner Gateway synchronisiert den freigegebenen Bestand anschließend über SFTP oder einen anderen sicheren Weg in das heutige Netz.

Damit wird die unsichere Protokollzone klein und kontrollierbar gehalten.

Cross-Platform-Transfer als kontrollierter Workflow

Bei heterogenen Systemen sollte zuerst feststehen, welche Information erhalten werden muss: nur Dateiinhalt oder auch Rechte, Forks, Zeiten und Originalnamen.

Danach wird ein Transfercontainer beziehungsweise Zielmedium gewählt, das diese Eigenschaften bewahren kann.

Abschließend werden Dateien auf dem Ziel nicht nur geöffnet, sondern per Hash und Metadatenvergleich geprüft.

Retro-zu-modern – ein robuster Ablauf

Historische Originalmedien werden zuerst vollständig gesichert, bevor einzelne Dateien für den Alltag extrahiert werden.

Der Transfer auf moderne Systeme erfolgt über eine passende Brücke: serielle Verbindung, Spezialadapter, Imagegerät oder Netzwerk.

Unveränderte Masterimages bleiben getrennt von konvertierten oder umbenannten Zugriffskopien.

• Originalmedium identifizieren und schreibgeschützt behandeln.
• Vollständiges Image oder Rohabbild erzeugen, wenn sinnvoll.
• Hash des Masters berechnen.
• Arbeitskopie erzeugen.
• Dateien oder Diskimage über die gewählte Brücke übertragen.
• Zeichensatz-, Namens- und Metadatenkonvertierungen protokollieren.
• Zielhash prüfen.
• Master und Zugriffskopie getrennt aufbewahren.

Modern zu modern – einfach heißt nicht automatisch korrekt

Zwischen aktuellen Systemen sind SFTP, rsync, SMB, HTTPS, USB-Laufwerke und Synchronisationsdienste leicht verfügbar.

Die technische Herausforderung verschiebt sich zu Metadaten, ACLs, Sparse Files, Symlinks und großen Datenmengen.

Für Archivkopien sollte ein bewusstes Verfahren mit Prüfsummen und Versionierung gewählt werden statt bloßer Drag-and-drop-Bequemlichkeit.

Große Dateien übertragen

Bei sehr großen Images und Videodateien sind Resume, stabile Leitung und ausreichend freier Zielspeicher entscheidend.

Temporäre Dateien können zusätzlichen Platz benötigen; komprimierte Container müssen gegebenenfalls erst vollständig geschrieben werden.

Ein abschließender SHA-256-Vergleich verhindert, dass ein scheinbar erfolgreich fortgesetzter Transfer unbemerkt fehlerhaft bleibt.

Viele kleine Dateien – Latenz statt Bandbreite wird zum Problem

Hunderttausende kleine Dateien verursachen Metadatenoperationen, Round-Trips und Verzeichnisupdates. Ein schneller Link kann dabei trotzdem schlecht ausgelastet sein.

Ein TAR- oder ZIP-Container kann den Transport stark vereinfachen, wenn die Zielmetadaten im gewählten Format erhalten bleiben.

Nach dem Transfer wird der Container geprüft und erst anschließend extrahiert.

Deduplizierung und Blockabgleich

Bei wiederholten Transfers großer ähnlicher Bestände kann ein block- oder hashbasierter Vergleich nur geänderte Inhalte bewegen.

rsync ist ein klassisches Beispiel auf Dateiebene; Backup- und Synchronisationssysteme können ähnliche Konzepte über ganze Repositories verwenden.

Deduplizierung reduziert Speicher- und Netzlast, erhöht aber die Bedeutung konsistenter Metadaten und Wiederherstellungslogik.

Delta-Transfer – Änderungen statt kompletter Dateien

Delta-Verfahren zerlegen Daten in Blöcke beziehungsweise Signaturen und suchen Übereinstimmungen zwischen alter und neuer Version.

Bei großen VM-Images oder Quellbäumen kann das erheblich Bandbreite sparen.

Komprimierte oder verschlüsselte Dateien ändern sich oft großflächig, wodurch Delta-Vorteile geringer werden.

Direktkabel oder Netzwerk?

Ein direktes serielles Kabel benötigt kaum Infrastruktur und eignet sich für alte Systeme. Ein Ethernetnetz bietet deutlich höhere Geschwindigkeit und flexible Protokolle.

Die beste Lösung hängt nicht nur von Durchsatz ab, sondern von verfügbaren Treibern, Sicherheitsanforderungen und Risiko für Originalhardware.

Ein einfacher Nullmodemtransfer kann für einen einmaligen 1980er-Rechner verlässlicher sein als der Versuch, eine exotische historische Netzwerkkarte wieder in Betrieb zu nehmen.

Wechselmedium oder Netzwerk?

Ein Wechselmedium schafft eine klare physische Übergabe und kann völlig offline bleiben. Dafür benötigt jede Seite kompatible Hardware und Dateisysteme.

Netzwerke vermeiden Medienwechsel, benötigen aber Protokollkompatibilität und Sicherheitskonfiguration.

Für kleine historische Datenmengen kann eine SD- oder Diskettenbrücke einfacher sein; für große Bestände ist Netzwerk meist effizienter.

Übertragungszeit realistisch abschätzen

Nominale Linkraten sind Bruttowerte. Protokolloverhead, Latenz, Dateisystem, Speichermedium und CPU reduzieren den tatsächlichen Durchsatz.

Eine 115200-bit/s-UART mit 8N1 kann nicht 115200 Byte pro Sekunde transportieren. Schon die Zeichenrahmung begrenzt die theoretischen Nutzbytes auf ungefähr ein Zehntel der Bitrate.

Bei modernen Gigabit-Links wird häufig das Speichermedium oder die Zahl kleiner Dateien zum eigentlichen Flaschenhals.

Der langsamste Abschnitt bestimmt den Transfer

Ein USB4-Link macht eine alte SATA-Festplatte nicht schneller als deren eigenes Interface und Medium.

Ein Gigabit-Netzwerk hilft wenig, wenn der Retrorechner Daten über eine langsame serielle Schnittstelle an einen Gateway liefert.

Zur Diagnose sollte deshalb die gesamte Kette betrachtet werden: Quelle, Dateisystem, CPU, Bus, Protokoll, Netz und Zielmedium.

Puffer – Geschwindigkeitsunterschiede entkoppeln

Puffer nehmen Daten kurzfristig auf, wenn Sender und Empfänger nicht exakt gleich schnell arbeiten.

UART-FIFOs, Betriebssystemcaches, TCP-Sendepuffer und Festplattencaches erfüllen jeweils ähnliche Grundfunktionen auf verschiedenen Ebenen.

Zu kleine Puffer verursachen Überläufe oder schlechte Auslastung, zu große Puffer können Fehler und Latenz länger verbergen.

Flusskontrolle auf mehreren Ebenen

RTS/CTS bremst eine UART, TCP bewirbt ein Empfangsfenster, ein Dateiprotokoll kann Blockbestätigungen verlangen.

Diese Mechanismen lösen ähnliche Probleme, wirken aber auf unterschiedlichen Ebenen.

Doppelte Flusskontrolle ist nicht grundsätzlich schlecht; wichtig ist, dass jede Schicht korrekt konfiguriert ist.

Fehlerwiederholung – von NAK bis TCP-Retransmit

XMODEM fordert einen fehlerhaften Block erneut an, TCP retransmittiert verlorene Segmente, rsync kann nur fehlende beziehungsweise geänderte Bereiche nachliefern.

Je höher die Wiederholungsebene liegt, desto mehr Kontext besitzt sie über Dateien und Zustände.

Bei instabilen Medien sollte jedoch nicht endlos wiederholt werden, wenn jeder mechanische Leseversuch weiteren Schaden verursachen kann.

Transferprotokolle und Logs aufheben

Ein Log mit Quelle, Ziel, Werkzeug, Version, Uhrzeit, übertragenen Dateien und Fehlern erleichtert spätere Nachvollziehbarkeit.

Bei automatisierten Migrationen ist dies fast ebenso wichtig wie der eigentliche Kopiervorgang.

Sensible Zugangsdaten dürfen dabei nicht im Klartext mitgeloggt werden.

Automatisierter Dateiaustausch

Skripte können wiederkehrende SFTP-, rsync-, SMB- oder lokale Kopiervorgänge zuverlässig reproduzieren.

Fehlercodes müssen geprüft und unvollständige Transfers klar behandelt werden.

Ein Skript, das immer mit Erfolg endet, obwohl ein Kopierschritt fehlgeschlagen ist, ist schlechter als ein manueller kontrollierter Transfer.

Idempotente Transfers

Ein idempotenter Ablauf kann mehrfach ausgeführt werden, ohne bereits korrekt übertragene Daten unnötig zu beschädigen oder zu duplizieren.

Hashvergleich, temporäre Dateien und atomare Umbenennung helfen dabei.

Das ist besonders für instabile Leitungen und große Migrationsprojekte wertvoll.

Offline-Transfer und Air-Gap

Ein Wechselmedium kann Daten zwischen Netzen übertragen, die bewusst nicht direkt verbunden sind.

Damit verschwindet das Netzwerkrisiko nicht; Schadsoftware kann über das Medium selbst wechseln.

Kontrollierte Scan-, Freigabe- und Schreibschutzprozesse sind bei sensiblen Umgebungen entscheidend.

Alte Dateien können weiterhin Schadcode enthalten

Historische DOS-Programme, Makros, Skripte oder Bootsektoren können Malware tragen.

Beim Transfer in moderne Archive sollte der Originalinhalt nicht still verändert werden; Analyse erfolgt auf Arbeitskopien in isolierter Umgebung.

Virenscannergebnisse sind Metadaten, keine Grundlage zum unprotokollierten Löschen historischer Master.

Personenbezogene Daten beim Systemtransfer

Festplattenimages, Mailarchive und Benutzerverzeichnisse können Passwörter, Adressen und private Kommunikation enthalten.

Ein technischer erfolgreicher Transfer bedeutet nicht, dass die Daten anschließend veröffentlicht werden dürfen.

Archivierung, Zugriff und Veröffentlichung müssen getrennt entschieden werden.

Transfermetadaten als Teil des Archivs

Bei historischen Migrationen sollte dokumentiert werden, wann, womit und aus welchem Ausgangssystem eine Datei übernommen wurde.

So bleibt erkennbar, ob Zeitstempel oder Dateinamen bereits bei einem früheren Transfer verändert wurden.

Diese Transfergeschichte kann später entscheidend sein, wenn verschiedene Versionen desselben Programms auftauchen.

Originalbytes und konvertierte Nutzkopie getrennt halten

Ein PETSCII-Text kann für heutige Lesbarkeit in UTF-8 konvertiert werden. Die UTF-8-Version ist nützlich, ersetzt aber nicht die ursprüngliche Bytefolge.

Dasselbe gilt für CRLF/LF-Konvertierung, entpackte Archive und aus Diskimages extrahierte Dateien.

Master und Derivat benötigen eindeutige Rollen statt einen einzigen überschriebenen Dateinamen.

Vor und nach einer Migration hashen

Der Quellhash wird gebildet, bevor eine Datei die alte Umgebung verlässt. Nach einem binären Transfer wird der Zielhash erneut berechnet.

Sind beide gleich, ist die Bytefolge unverändert angekommen.

Bei beabsichtigter Konvertierung werden Quell- und Zielhash plus Konvertierungswerkzeug dokumentiert, statt Gleichheit zu erwarten.

Bei alten Datenträgern zuerst Image, dann Dateikopie

Ein vollständiges Image erhält mehr Kontext als die reine Auswahl sichtbarer Dateien.

Gelöschte Verzeichniseinträge, Bootblöcke, spezielle Dateisystemstrukturen und versteckte Daten können sonst verloren gehen.

Für Alltagszugriff werden anschließend Dateien aus einer Kopie des Images extrahiert.

Transfer ist Teil des digitalen Erhalts

Digitaler Erhalt endet nicht beim Imaging. Masterdateien müssen auf neue Speichersysteme migriert werden, bevor alte Medien oder Server ausfallen.

Jede Migration ist wieder ein Dateitransfer und benötigt Integritätskontrolle.

Die vertiefte Preservation-Seite liegt auf emulation-und-digitaler-erhalt.htm.

Backupwege und Dateitransfer unterscheiden

Ein Backupwerkzeug kann Daten über Netzwerk, USB oder lokale Busse übertragen. Der Transportweg sagt wenig über Versionierung und Wiederherstellbarkeit aus.

Ein einfacher SFTP-Upload ist noch kein Backupkonzept, wenn alte Versionen sofort überschrieben werden.

Die Backup-Vertiefung steht auf datensicherung-und-backups.htm.

Prüfsummen dauerhaft neben den Daten halten

Hashes sollten nicht nur beim einmaligen Transfer im Terminal erscheinen. Ein Manifest gehört dauerhaft zum Archivbestand.

Bei späteren Migrationen lässt sich dadurch prüfen, ob die neue Kopie noch dem ursprünglich übernommenen Master entspricht.

Hashalgorithmus und Erstellungsdatum werden mit dokumentiert.

Welcher moderne Weg passt wozu?

Für administrativen Servertransfer ist SFTP oder rsync über SSH häufig sinnvoll. Für Dateifreigaben im LAN bieten SMB oder NFS direkte Dateisystemsemantik. Für Webdownloads ist HTTPS universell.

USB-Mass-Storage ist praktisch für Offline-Übergabe. MTP eignet sich für Geräte, die ihr internes Dateisystem nicht direkt freigeben sollen. Synchronisationsdienste sind komfortabel für laufende Replikation.

Kein Verfahren ist pauschal das beste. Entscheidend sind benötigte Metadaten, Sicherheitsmodell, Datenmenge, Plattformen und Wiederholbarkeit.

Welcher Retro-Weg passt wozu?

Ein Rechner mit funktionierender RS-232-Schnittstelle lässt sich oft am universellsten per Nullmodem anbinden. XMODEM oder Kermit funktionieren mit sehr wenig Infrastruktur.

Bei vielen Dateien und vorhandener Netzwerkkarte kann FTP in einem isolierten Retro-LAN komfortabler sein.

Für seltene Disketten ist dagegen ein vollständiges Image über passendes Laufwerk oder Fluxreader wichtiger als die direkte Dateiübertragung vom Originalsystem.

Vergleich typischer Wege

Die folgende Matrix ordnet Verfahren grob ein. Reale Leistung hängt stark von Hardware und Implementierung ab.

Besonders wichtig ist die Trennung zwischen komfortabler Zugriffsmethode und archivgeeigneter Masterübernahme.

Häufige Irrtümer über Dateitransfer

Ein USB-C-Kabel definiert kein Dateiprotokoll. Ethernet ist keine Dateifreigabe. Ein erfolgreicher Kopierdialog beweist keine Byteidentität. Und ein gleich großes Diskettenmedium garantiert keine Formatkompatibilität.

SFTP ist nicht FTP über SSH, FTPS ist nicht SFTP, und rsync ist nicht automatisch ein Backup.

Cross-Platform-Transfer betrifft nicht nur Dateiinhalt, sondern auch Namen, Zeiten, Rechte, Links, Forks und Zeichensätze.

• RS-232 ist die Verbindung, XMODEM/Kermit/ZMODEM sind Transferprotokolle.
• Nullmodem ist eine Rollen- und Signalverdrahtung, kein Modem.
• Baud und bit/s sind nicht grundsätzlich identisch.
• Parallel-Direktkabel und Druckerkabel sind nicht dasselbe.
• Gleiche Diskettengröße bedeutet nicht gleiches Format.
• FAT ist eine gute Austauschbasis, bewahrt aber nicht alle Metadaten.
• FTP ASCII kann Dateien verändern; Binärdaten gehören in Image/Binary-Modus.
• SFTP und FTPS sind verschiedene Protokollfamilien.
• USB Mass Storage überträgt Blöcke, MTP überträgt Objekte.
• Synchronisation ist kein unveränderliches Backup.
• Hashgleichheit prüft Dateiinhalt, nicht Dateirechte oder Zeitstempel.
• Archive und Diskimages sollten vor Cross-Platform-Transfer bewusst gewählt werden.

Checkliste für einen nachvollziehbaren Dateitransfer

Bei wertvollen oder historischen Daten sollte der Transfer so dokumentiert werden, dass Quelle, Transformation und Ziel später noch verständlich sind.

Die folgende Liste reicht vom Retro-Nullmodem bis zur modernen Servermigration.

• Quelle und Ziel eindeutig identifizieren.
• Entscheiden, ob nur Dateiinhalt oder vollständige Metadaten erhalten werden müssen.
• Bei historischen Medien zuerst ein Masterimage erstellen, wenn möglich.
• Binär- oder Textmodus bewusst wählen.
• Passende Zeichenkodierung und Zeilenenden dokumentieren.
• Dateinamenregeln und Case-Sensitivity des Ziels prüfen.
• Bei seriell: Baudrate, Datenbits, Parität, Stopbits und Flow Control notieren.
• Bei Nullmodem: tatsächliche Handshakeverdrahtung dokumentieren.
• Bei Netzwerk: Protokoll und Sicherheitsmodell festhalten.
• Bei USB: Geräteklasse beziehungsweise Transferverfahren benennen.
• Quellhash vor der Übertragung berechnen.
• Unvollständige Dateien als temporär kennzeichnen.
• Zielhash nach Transfer prüfen.
• Konvertierungen niemals mit dem unveränderten Master verwechseln.
• Transferlog und Toolversion bei wichtigen Migrationen archivieren.
• Synchronisationsziele nicht als einzige Archivkopie betrachten.

Einordnung im SSLXY-Archiv

Dateitransfer verbindet nahezu alle historischen Technikbereiche: serielle Kommunikation, Modems, Mailboxen, Disketten, SCSI, Netzwerke, Betriebssysteme und heutige Archivspeicher.

Direkte Vertiefungen sind Schnittstellen und Kabel, Interfaces, Modems und Dataphon, Mailboxen/BBS, Dateisysteme und Datenträger, Netzwerk und Heimvernetzung und Emulation und digitaler Erhalt.

Die zentrale Perspektive bleibt systemübergreifend: Ein guter Transfer bewahrt nicht nur Bytes, sondern macht sichtbar, welche Ebene bewusst übersetzt und welche unverändert erhalten wurde.

Verwandte Themen im SSLXY-Archiv

Dateiaustausch ist eine Querschnittsfunktion zwischen Rechnern, Medien und Netzen. Die wichtigsten direkten Nachbarthemen sind hier zusammengefasst.