Backslashes in released zip archives paths
Describe the bug
In relased zip archives tgere are backslashes in paths. Zip uses forward slash as path separator.
It's a problem add not all un/zip clients assume \ to be a /.
To Reproduce
Get the released archives and see the path names, like cmake\hwy\hwy-config-release.cmake.
Expected behavior
To use forward slashed as path separator in zips.
Environment
- OS: Linux
Additional context
specification is clear about that:
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 '/'
Might this be cause by using an too old version of Powershell, see https://github.com/PowerShell/Microsoft.PowerShell.Archive/issues/48 ? Is this still a problem in the released arxives of v0.11.0?
Is this still a problem in the released arxives of v0.11.0?
Yes.
$ unzip -l jxl-x64-windows.zip
Archive: jxl-x64-windows.zip
Length Date Time Name
--------- ---------- ----- ----
824 09-13-2024 07:19 cmake\hwy\hwy-config-release.cmake
2827 09-13-2024 07:18 cmake\hwy\hwy-config-version.cmake
4344 09-13-2024 07:19 cmake\hwy\hwy-config.cmake
311 09-13-2024 07:18 pkgconfig\libbrotlicommon.pc
339 09-13-2024 07:18 pkgconfig\libbrotlidec.pc
339 09-13-2024 07:18 pkgconfig\libbrotlienc.pc
278 09-13-2024 07:18 pkgconfig\libhwy.pc
362 09-13-2024 07:19 pkgconfig\libjxl.pc
332 09-13-2024 07:19 pkgconfig\libjxl_cms.pc
359 09-13-2024 07:19 pkgconfig\libjxl_threads.pc
Might this be cause by using an too old version of Powershell
Don't use Powershell then. Use Zip, like Info-ZIP.
Thanks for checking! I didn't quite understand if this can be reproduced with an up-to-date version of powershell or not.
What version did you use here?
Ah, I meant "what version of PowerShell?"
I don't use Powershell. In Linux?
And what it has to do with me? You, I mean a in a repo, produce this file. I only point out its problems, problems that user/s have - when unpacking this archive can produce files with backslashes in names. I can only assume that these backslashes meant to be path separators, but they're not.
Sorry for the confusion! I didn't read carefully enough. In any case, I investigated the problem, and the root cause is an older of Compress-Arxive we used for the releases. We plan now to switch to 7z, where the problem with the slashes will not be present. See #3852
We plan now to switch to 7z
Zip (InfoZip) would be just fine. Actually it was 7zip having trouble with that zip file. InfoZip warned about the problem but unpacked it correctly, I mean with 'intended' paths.