Fix the way ZipFile deals with slashes

ZIP format specification says that:

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 ‘/’ as opposed to backwards slashes ‘\’

But it seems that:

  • ZipFile::Builder accepts storedPathname arguments containing backward slashes without problems. I believe they should either be converted to forward slashes (preferred), or an assertion should be triggered.

  • ZipFile::ZipEntry member filename is populated “as is” with the path stored in the ZIP file. The problem here is that there are ZIP tools that (especially on Windows) don’t follow the specification and store paths with backward slashes. I believe the filename member should always have forward slashes used, converting them when necessary.
    If that is too much of a breaking change, store the correct value in another member named e.g. partialPath (also fixing the fact that it may not be a simple filename, but an entire partial path)

The latter would also result in a cleaner code for uncompressEntry(), which currently has to deal with the possibility that either forward or backward slashes are used, which is fundamentally wrong

I was just about to post a feature request for this…

Currently, zips I (naively) created on Windows with file.getRelativePathFrom(otherFile) open up on Mac with backslashes in the name.

As @yfede says, the spec does not allow backslashes, so I would call changing the current behaviour a correction. But at worst it’s a very nice feature for JUCE to take care of us if we don’t get around to reading the zip file specification. It’s on my list, honest.

2 Likes