Archive Packaging Considerations

[SilverSurferNHS]

Issue:
Folder structure are being packaged as files and not true folder structure.
Example File:
cache\SCUS-94236\gcc\win-x64\cg4_0cec55ab\00000000_5594E069.dll

The Linux release archive (TombaRecomp-v0.7.0-alpha-windows-x64.zip) contains internal file paths using backslashes \ as directory separators instead of forward slashes /. This violates the official ZIP specification requiring forward slashes for path separators inside ZIP archives, regardless of the source platform.

Effect on Linux/macOS:
Since standard Linux/macOS unzip tools (Ark, GNOME Archive Manager, unzip) correctly follow the spec, they treat the backslashes as literal characters in the filename rather than directory separators. This causes every extracted file to land flat in the output directory with a mangled name like:
cache\SCUS-94236\gcc\win-x64\cg4_0cec55ab\00000000_5594E069.dll
instead of the intended nested structure:
cache/SCUS-94236/gcc/win-x64/cg4_0cec55ab/00000000_5594E069.dll
This breaks the release on any non-Windows system and the extracted files aren't usable without manual reconstruction of the folder hierarchy.

Possible Cause:
Building the archive with PowerShell's Compress-Archive cmdlet, which is known to use backslash separators
Using an older .NET Framework version (pre-4.6.1), whose ZipArchive class had this exact bug before Microsoft fixed it specifically to comply with the ZIP spec

Possible Fix:
Switch the release-packaging step (likely in the CI workflow) to a spec-compliant zipping tool. A few reliable options:
7-Zip (7z a -tzip release.zip ./folder/*) - correctly uses forward slashes
Python's zipfile module - spec-compliant by default
If staying with PowerShell, ensure it's using an up-to-date .NET runtime (4.6.1+), though switching tools entirely is more reliable

Workaround

find . -name '*\\*' | while read -r f; do
  newpath=$(echo "$f" | tr '\\' '/')
  mkdir -p "$(dirname "$newpath")"
  mv "$f" "$newpath"

This fixes the folder/file structure and allows for it to run appropriately in wine\proton under linux

Why this matters and who this effects
Linux users who run programs through Wine or Proton or other Wine wrapping runners.
This will be a non-issue if you choose to release a linux specific build with a linux oriented CI workflow for binary building and packaging.

Happy to test a fixed release build if useful. Thanks for the project :) I really appreciate the work!

[mstan]

Hello!

I've updated the latest build to be more conscious of pathing for sake of Linux. I've also attached an experimental AppImage as well, so you can give both a try and let me know how those go.

https://github.com/mstan/TombaRecomp/releases/tag/v0.11.0-alpha

Thanks!