Dies geschieht, weil einige Windows-Tools anscheinend Backslashes verwenden (\ ) als Trennzeichen, wo sie Schrägstriche verwenden sollten (/ ). Backslash in Unix kann ein Teil des Datei- oder Verzeichnisnamens sein.
.ZIP File Format Specification (Version:6.3.5, als ich dies schreibe, überarbeitet am 20. November 2018) besagt:
4.4.17.1 Der Name der Datei, optional mit relativem Pfad. Der gespeicherte Pfad DARF KEINEN Laufwerks- oder Gerätebuchstaben oder einen führenden Schrägstrich enthalten. Alle Schrägstriche MÜSSEN Schrägstriche / sein im Gegensatz zu umgekehrten Schrägstrichen \ für Kompatibilität mit Amiga- und UNIX-Dateisystemen usw. Wenn die Eingabe von der Standardeingabe kam, gibt es kein Dateinamensfeld.
Diese Datei wird von Microsoft in einem Dokument Mitigation erwähnt:ZipArchiveEntry.FullName Pfadtrennzeichen:
Beginnend mit Apps, die auf .NET Framework 4.6.1 abzielen, das in ZipArchiveEntry.FullName verwendete Pfadtrennzeichen Die Eigenschaft hat sich vom umgekehrten Schrägstrich (\ ), die in früheren Versionen von .NET Framework verwendet wurde, in einen Schrägstrich (/) umwandeln ). [...]
Auswirkung
Die Änderung bringt die .NET-Implementierung in Übereinstimmung mit Abschnitt 4.4.17.1 der .ZIP-Dateiformatspezifikation und ermöglicht das Dekomprimieren von .ZIP-Archiven auf Nicht-Windows-Systemen.
Beim Dekomprimieren einer ZIP-Datei, die von einer App erstellt wurde, die auf eine frühere Version von .NET Framework auf Nicht-Windows-Betriebssystemen wie dem Macintosh abzielt, bleibt die Verzeichnisstruktur nicht erhalten. Auf dem Macintosh erstellt es beispielsweise eine Reihe von Dateien, deren Dateiname den Verzeichnispfad zusammen mit einem Backslash (\ ) Zeichen und den Dateinamen. Dadurch bleibt die Verzeichnisstruktur dekomprimierter Dateien nicht erhalten.
Beachten Sie, dass das Problem auftreten kann, wenn der Archivierer eine alte Version von .NET Framework verwendet hat oder wenn er es überhaupt nicht verwendet hat, sondern seinen eigenen (unabhängigen) Ansatz für Zip-Dateien implementiert hat.
Dasselbe Problem kann mit rar auftreten:Unrar erzeugt Dateien mit Backslashes im Namen anstelle der richtigen Verzeichnishierarchie.
Möglicherweise finden Sie diese Frage zu Unix &Linux SE hilfreich:Konvertieren Sie eine von Windows erstellte ZIP-Datei nach Linux (Problem mit internen Pfaden). Mein (etwas experimenteller) Ansatz ist in dieser Antwort enthalten.
Dies ist eigentlich ein Fehler in Microsoft.PowerShell.Archive :
https://github.com/PowerShell/Microsoft.PowerShell.Archive/issues/48
... die in diesem PR behoben werden, geplant für Version 1.2.3:
https://github.com/PowerShell/Microsoft.PowerShell.Archive/pull/62
In der Zwischenzeit ist dies eine schnelle Lösung (Credit):
for file in *\\*; do target="${file//\\//}"; mkdir -p "${target%/*}"; mv -v "$file" "$target"; done