#2312 7-zip can't handle path separators

[Nea Manole]

In the attached archive (I've removed most of the content to keep it small), looking at the contents shows path separators as a dot, and when the archive is extracted the directory structure is not created as it should be. WinRAR seems to be able to deal with the separators.

I'm using Windows 10, 7-zip 21.03 beta x64

[Nea Manole]

The content look like this:

https://imgur.com/a/tLMNEMB

[Igor Pavlov]

It was implemented so in 7-Zip for compatibility with linux.
Try to extract that archive in linux and compare with 7-Zip.
How did you create that archive?

[a p]

This bug is also confirmed on our side, on Windows, while working on version 21.07.
It is working properly without this bug on version 19.00

You said this behavior was implemented for the sake of a Linux compatibility, but when a 7z file is extracted on a Windows machine, it should behave as in version 19.00

[a p]

This bug still exists. Will it be fixed?

Please look at the attached sample (on the first post). 7-Zip v24.03 for Windows can't handle it, while v19.00 can. Windows' built-in ZIP program can also handle it.

Thanks!

[Sam Tansy]

It's not a bug. Zip specification says:

4.4.17 file name: (Variable)

  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 '/'

[Igor Pavlov]

It's not bug of 7-zip.
It's feature for better compatibility with Linux.

Linux allows backslashes in file names:
2024\03\28.txt
It's just one file with such name in Linux.
it's not 2024 folder there.
So if you extract such archive in Linux, you will get one file.
7-Zip for Windows also creates one file in that case.
And you can see original 2024\03\28.txt name in WSL in Windows.

[Sam Tansy]

It's feature for better compatibility with Linux.

It's not compatibility with Linux but with specification.

If you try to argument it this way, windows users are going to rationalise it by

but '\' is valid path separator

Well, it is. In DOS/Windows. It is not in *nix/Linux/BSD.
Specification specifically says forward slash '/'.

[Igor Pavlov]

specification doesn't tell us what unpacker in Windows must do, if archive uses \ in filenames.
We still need to unpack it in Windows with some supported file path.
way-1 : replace it with some character. 7-Zip replaces it with
WSL unicode character that represents \. Also we could replace it with _ (underscore).
way-2 : keep \ during unpacking. Another windows unpackers do it so. But it creates folders.

So I have selected the way that is more compatible with Linux and WSL. So if we unpack same archive in Windows and in WSL (with linux version of 7-zip), we still get same tree structure after unpacking and same names in WSL (name with backslash).

[Sam Tansy]

specification doesn't tell us what unpacker in Windows must do, if archive uses \ in filenames.

Yes, but it's not specification's job. Specification says that .ZIP uses '/' as a separator. That means '\' is not a separator.
What you do, or have to do, to make it work under Windows, or any other OS, for that matter, is not a specification's concern. If I create a new operating system with '%' as path separator, should I complain to Mr Katz that they used wrong path separator?

It is also, and just as important for developers as is for users. User is not bound to any system, Windows including, and they want their data back, regardless of 'slash wars' between microsoft and the rest of the world.

[Igor Pavlov]

your claim was wrong:

It's not compatibility with Linux but with specification.

We have many possible ways to work with such names in Windows.
And we must select some way from all these possible ways.
And the way selected by 7-zip provides more compatibility with Linux and WSL.
So it's feature. It's not bug in 7-Zip.
There is bug in software that was used to created that archive.
But selected way we work with such archive in Windows is feature.

[a p]

Ok, I understand now.

1. A compressed file in Linux can have a backslash in its filename, as a legitimate character and not as a separator.
2. When such file is about to be uncompressed in Windows, which doesn't accept a backslash as a filename character, but only as a separator, we have these two options:
   2.1. Replace it with another character.
   2.2. Use it as a path separator.

7-Zip defaults to 2.1. with an equivalent character to backslash in WSL (I didn't know such equivalent was needed). This better complies with the specifications, as the second option contradicts it.

Unfortunately, in the real world, not all ZIP creators strictly follow the specifications, and create such ZIP files with backslashes as separators. When we get such files, we still wish to extract them to their original path structure, but currently there is no such a way to do so with 7-Zip (or is there?)

For these specification incompatible files, I would like to suggest a new boolean option on the Extract form: 'Handle backslashes as path separators'.

Thanks!

[Igor Pavlov]

Unfortunately, in the real world, not all ZIP creators strictly follow the specifications, and create such ZIP files with backslashes as separators.

ZIP creators will follow ZIP specification, if users will notify them that they don't follow ZIP specification.
So 7-Zip now helps to make their software better.

[a p]

@ipavlov,
We agree that there are tons of apps and old libraries which create incompatible ZIP files (e.g. .NET prior to version 4.6,1), which need to be fixed. Unfortunately, they remain the source for an enormous number of incompatible files, and that won't change soon.

But meanwhile, 7-Zip is not capable of extracting these files at all, although it could have done so on older versions. This change broke the compatibility with older versions, with no alternative option to maintain the original behavior.

@ipavlov, @tansy,
To be a bit petty, that specification section requires that:

All slashes MUST be forward slashes '/' as opposed to backwards slashes '\' for compatibility with Amiga and UNIX file systems etc.

When referring "all slashes" as "all slashes" rather than "all separators", that strictly means that:
1. Backslashes are not allowed at all in a path within a ZIP file, and implies that backslashes must be written as forward slashes.
2. All these slashes in a path within a ZIP file are used as separators ("for compatibility with Amiga and UNIX file systems").

The specification says nothing about the source path in the creation phase. That is, if there was originally a backslash, whether it was a separator or not, now it must be changed to a forward slash, effectively making it a separator.

So, if it is desired to be as strict as possible as instructed by the specification, when working with incompatible ZIP files with backslashes, a better solution would be to treat them as file separators.

@ipavlov,
Please be patient with me :-)

I'd like to revise my previous suggestion, by moving the suggested 'Handle backslashes as path separators' option from the Extract form, to a more hidden place - the Settings section.

Today, for such incompatible files I use windows built-in ZIP extractor, but I prefer to do so with your app, which is the default app on my PC, for its other capabilities.

Thanks again!