"Unexpected end of archive"

Die Meldung, die du siehst, ist ein starker Hinweis darauf, mit welchem Tool und welchem Format du es zu tun hast — es lohnt sich, sie zu entschlüsseln, bevor du sonst etwas tust, denn jedes scheitert an einem leicht anderen Punkt.

• WinRAR — "Unexpected end of archive." Der Klassiker. WinRAR erreichte das Ende der Datei, während ein Block-Header oder der Archiv-Endmarker noch sagte, es müsse mehr geben. Gilt sowohl für .rar als auch für die ZIPs, die WinRAR öffnet.
• 7-Zip — "Unexpected end of data" (manchmal "Unexpected end of archive"). 7-Zip unterscheidet ein sauberes Abschneiden ("end of data") von einer falschen Signatur ("is not archive") und von einem gekippten Byte ("Data error"). "End of data" heißt konkret, dass der Stream mittendrin abbrach — ein Abschneiden, kein Durcheinander.
• Info-ZIP unzip — "cannot find zipfile directory … End-of-central-directory signature not found." unzip sucht vom Ende her rückwärts nach PK\x05\x06 und findet es nie, kann also nicht einmal seine Dateiliste aufbauen. Die Daten mögen in Ordnung sein; verloren ist der Index.
• Windows-Explorer — "The compressed (zipped) folder is invalid." Der eingebaute Entpacker ist der unspezifischste von allen. Meist ist es dieselbe Geschichte vom fehlenden EOCD — siehe "Compressed folder is invalid" für genau diesen Wortlaut.
• macOS Archivierungsprogramm — "Error 2 – No such file or directory." Berüchtigt undurchsichtig: Die „Datei“, die es nicht finden kann, ist der Eintrag des zentralen Verzeichnisses, den es am Ende erwartet hat. Dasselbe Abschneiden, mit einer einzigartig unhilfreichen Meldung.
• Python zipfile — BadZipFile: File is not a zip file, oder ein Fehler beim .read(). Fehlt das EOCD, weigert sich zipfile schon zu öffnen; ist nur ein später Eintrag abgeschnitten, öffnet es problemlos und scheitert erst, wenn du dieses Member liest.
• GNU tar / gzip — "Unexpected EOF in archive" / "unexpected end of file." Eine völlig andere Struktur (gar kein zentraler Index) — weiter unten behandelt.

Steht dein Wortlaut auf dieser Liste, hast du fast sicher eine zu kurze Datei, keine durcheinandergeratene — und die Wiederherstellung ist dieselbe, egal welches Tool sie gemeldet hat.

Jedes Archivformat führt eine kleine, kritische Struktur, die sagt: „Das Archiv ist vollständig, und hier ist sein Inhalt indexiert.“ Diese Struktur sitzt am Ende der Datei oder nahe daran — also genau in der Region, die ein Abschneiden zuerst zerstört. Zu wissen, welcher Marker fehlt, sagt dir, wie viel sich retten lässt.

• ZIP — End Of Central Directory (PK\x05\x06). Ein ZIP ist eine Folge lokaler Einträge (jeder beginnt mit PK\x03\x04), dann ein zentrales Verzeichnis aus PK\x01\x02-Datensätzen und zuletzt das 22-Byte-EOCD. Das EOCD ist der Index. Große Archive oder solche über 4 GB ergänzen einen ZIP64-EOCD-Datensatz (PK\x06\x06) und einen Locator (PK\x06\x07) direkt davor. Verlierst du das Ende, verlierst du den Index — aber nicht die lokalen Einträge, die sich selbst beschreiben.
• RAR 4 — End-of-Archive-Block (HEAD_TYPE 0x7B). Nach der Signatur Rar!\x1A\x07\x00 speichert RAR4 unabhängig decodierbare Blöcke und schließt mit einem Abschlussblock. Dateien vor dem Schnitt decodieren weiterhin; ein RAR, das mit einem Wiederherstellungsdatensatz erstellt wurde, kann fehlende Blöcke sogar komplett rekonstruieren.
• RAR 5 — End-of-Archive-Header (Header-Typ 5). Signatur Rar!\x1A\x07\x01\x00, ein neu gestaltetes Header-Format, dieselbe Idee: ein eigener End-Header, den ein Abschneiden entfernt.
• 7z — der Start-Header verweist auf einen End-Header am Dateiende. Nach der Signatur 37 7A BC AF 27 1C und zwei Versionsbytes sitzt ein 20-Byte-Start-Header mit NextHeaderOffset, NextHeaderSize und einem CRC — ein Zeiger auf die Header-Datenbank ganz am Ende der Datei. Schneide die Datei ab, und dieser Zeiger zielt hinter das letzte Byte. Schlimmer noch: .7z nutzt standardmäßig solide Kompression und verkettet die Dateien zu einem einzigen Stream, sodass ein verlorenes Ende jede Datei nach dem letzten vollständigen Block zerstören kann.

Das Muster ist universell: Die Metadaten, die der Entpacker zuerst braucht, werden zuletzt gespeichert — also sind es die Metadaten, die ein Abschneiden zuerst tötet. Deshalb ist "unexpected end" so häufig und deshalb sind die Daten selbst meist noch zu retten.

Tar ist die Ausnahme und eine eigene Notiz wert, weil die Diagnose anders ausfällt. Ein .tar hat überhaupt keinen zentralen Index: Es ist eine schlichte Folge von 512-Byte-Datensätzen — ein Header-Block pro Datei (der ustar-Header mit Name, Größe und einer Prüfsumme), dann die Dateidaten, aufgefüllt bis zur nächsten 512-Byte-Grenze. Das Archiv gilt als beendet durch zwei aufeinanderfolgende, komplett mit Null gefüllte 512-Byte-Blöcke. Kamen diese abschließenden Nullblöcke nie an, druckt tar "Unexpected EOF in archive", obwohl jede vollständig geschriebene Datei tadellos extrahierbar ist — tar läuft die Datensätze schlicht von vorn nach hinten durch und rettet so alles bis zu dem Byte, an dem ihm die Daten ausgingen.

Ein .tar.gz (oder .tgz) hüllt diesen Tar-Stream in gzip. Ein gzip-Member ist ein 10-Byte-Header (1F 8B 08 …), der Deflate-Stream und ein 8-Byte-Trailer mit einem CRC-32 der unkomprimierten Daten und der ISIZE (Originalgröße modulo 2³²). Schneide es ab, und gzip meldet "unexpected end of file" — es dekomprimiert korrekt bis zum Schnitt und hat dann keinen Trailer, gegen den es prüfen könnte. Die Rettung folgt demselben Prinzip wie bei ZIP: so weit vorwärts decodieren, wie es die intakten Bytes erlauben.

"Unexpected end" ist das Symptom. Die Ursache entscheidet über deinen besten Zug, und davon gibt es drei:

• Ein Browser-Download, der hängen blieb oder abgebrochen wurde. Kam das Archiv über einen Link und die Übertragung endete nie (ein zurückgebliebenes .crdownload/.part, ein "Failed – Network error"), ist die Mechanik, welche Bytes genau überleben, speziell — siehe einen unterbrochenen ZIP-Download.
• Eine Cloud-Datei, die vollständig aussieht, es aber nicht ist. Drive, Dropbox und OneDrive können dir eine in .zip umbenannte HTML-Fehlerseite oder eine unvollständige Synchronisierung untergeschoben haben — ein Abschneiden, das sich als Beschädigung ausgibt. Um eine zu kurze Datei von echtem Bit-Verfall zu unterscheiden, siehe wie du ein beschädigtes Cloud-Archiv diagnostizierst.
• Die Quelle selbst ist zu kurz. Fehlt dem Original tatsächlich seine Endsequenz, kann kein Tool die fehlenden Bytes erfinden — aber IntactFile extrahiert dennoch alles, was vor dem Schnitt geschrieben wurde. Lege es oben ab, um die intakten Einträge zu retten.

In jedem Fall ist die Rettung selbst identisch und läuft vollständig in deinem Tab: IntactFile ignoriert den fehlenden Endmarker, scannt vom Dateianfang her vorwärts, fängt jeden intakten Eintrag ab und dekomprimiert, was die überlebenden Bytes erlauben — reines TypeScript, ohne installiertes Archiv-Tool, und du kannst im Netzwerk-Tab bestätigen, dass nie auch nur ein Byte eines privaten Archivs dein Gerät verlässt.