Argthtjtr

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>

assetsChanges.txt

assetsDefaultConfig,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?

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.