Zip files expand with backslashes on Linux, no subdirectories

Question

So, weirdly, I can unzip a file a friend made on windows. What it gives out is strange, and incorrect in a way I've not seen before.

<base directory stuff>
assets\Changes.txt
assets\DefaultConfig,txt

And so on. It's clearly meant to be a subdirectory, but they come out as files with a backslash in them.

They made it on Windows (using the Compress-Archive powerscript command), I attempted to extract it on Linux, using both the ark program from KDE, and archive-manager from GNOME.

What's going on here?

Solution 1

It happens because some Windows tools apparently use backslashes (\) as separators where they should use forward slashes (/). Backslash in Unix can be a part of file or directory name.

.ZIP File Format Specification (version: 6.3.5 when I'm writing this, revised November 20, 2018) states:

4.4.17.1 The name of the file, with optional relative path. The path stored MUST NOT contain a drive or device letter, or a leading slash. All slashes MUST be forward slashes / as opposed to backwards slashes \ for compatibility with Amiga and UNIX file systems etc. If input came from standard input, there is no file name field.

This file is mentioned by Microsoft in a document Mitigation: ZipArchiveEntry.FullName Path Separator:

Starting with apps that target the .NET Framework 4.6.1, the path separator used in the ZipArchiveEntry.FullName property has changed from the backslash (\) used in previous versions of the .NET Framework to a forward slash (/). [...]

Impact

The change brings the .NET implementation into conformity with section 4.4.17.1 of the .ZIP File Format Specification and allows .ZIP archives to be decompressed on non-Windows systems.

Decompressing a zip file created by an app that targets a previous version of the .NET Framework on non-Windows operating systems such as the Macintosh fails to preserve the directory structure. For example, on the Macintosh, it creates a set of files whose filename concatenates the directory path, along with any backslash (\) characters, and the filename. As a result, the directory structure of decompressed files is not preserved.

Note the problem may exist if the archiver used some old version of .NET Framework or if it didn't use it at all but implemented its own (independent) approach to zip files.

One may experience the same problem with rar: Unrar creating files with backslashes in names instead of proper directory hierarchy.

You may find this question on Unix & Linux SE helpful: Convert a Windows-created ZIP to Linux (internal paths issue). My (somewhat experimental) approach is in this answer.

Solution 2

This is actually a bug in Microsoft.PowerShell.Archive:

https://github.com/PowerShell/Microsoft.PowerShell.Archive/issues/48

...which will be resolved in this PR, slated for version 1.2.3:

https://github.com/PowerShell/Microsoft.PowerShell.Archive/pull/62

In the meantime, this is a quick fix (credit):

for file in *\\*; do target="${file//\\//}"; mkdir -p "${target%/*}"; mv -v "$file" "$target"; done

Comments

[mikebridge]

Why downvote this? The OP asked why he can't open a zip file created by "Compress-Archive" on PowerShell ("but I want to know why this happens"), and this is the specific bug that caused the problem. The accepted answer is generally useful but this is the exact reason.

[mikebridge]

I haven't tried ark, but it looks like Debian's unzip 6.00 seems able to handle Windows paths.

[LudvigH]

here in 2021 i still have this issue creating archives with powershell getting backslashes. sad.