i’ve bundled a few command-line executable into a package, which i’m able to fetch and install via my build.zig and build.zig.zon… since these executables are host-OS specific, i actually have different URLs for windows, linux, macos…
all is well on windows and linux… but for some reason the macos package (when fetched, deflated, and eventually installed) does NOT preserve the 0777 permissions i had assigned to the original files…
i’ve tried this with .zip and .tar.gz archives – same problem… most recently, i completely removed by global and local cache; zig build (re-)fetched the packages, of course… but even when i inspected the p/<hash> folder, the exploded content only had 0644 permissions on the executables…
again, all is well on windows and linux… macos is the issue…
setting umask 0 did NOT fix the problem… i’ve reverted back to umask 0022
when i simply download the .zip file (or the .tar.gz alternative) and deflate it, all of my original 0777 permissions are preserved…
running zig build from the SAME shell eventually installed my executables with 0644 permissions… even after completely removing the global cache, the deflated .zip (.tar.gz alternative) held in the global cache was already missing permissions after it was fetched…
here’s the other strange thing: i have ANOTHER archive that i also use under macos; and this archive has a rather deep hierarchy of files… here too, ALL files were set to 0777… but for some reason, this archive deflates correctly…
the other archive is a .tar.gz… i’ve tried a .tar.gz as well as a .zip with my small archive containing executables… BOTH fail in exactly the same way under macos
If it isn’t umask, I don’t know what the reason is for the files missing permissions, whether it is something that zig does explicitly or whether it is a bug.
Maybe you could do something like here, until you find out the reason?:
Maybe another reason would be that the user that executes zig fetch doesn’t have the permissions to create a file with those permissions? So basically I mean, maybe there are other things besides umask that can interfere with the resulting permissions? (My knowledge is limited in this area, but I think something like this could be the case)
yeah, something like this was always my fallback… to keep things simple and uniform, i’ll probably do this for ALL such packages on ALL hosts – even though it works “almost everywhere”…
FWIW, i used to deliver these sorts of 3rd-party-tool artifacts via npm… and i seem to have similar problems across platforms, so i had my npm install explicitly set permissions in the aftermath…