files extracted from zips are missing execute permissions

[travisstaloch]

Zig Version

0.14.0-dev.875+ebd0c6ffd

Steps to Reproduce and Observed Behavior

This issue was reported here. That project uses the package manager to download zips from https://github.com/protocolbuffers/protobuf/releases/. When I unzip one of the zip files manually, the permissions look fine.

-r-xr-xr-x 1 17M May 22 11:45 protoc

But with the package manager I guess they turn into the following as reported in the issue above.

-rw-r--r-- protoc

I asked @marler8997 about this and he said

I don't think I implemented the extension for unix file permissions.

So it sounds like this just hasn't been implemented yet. zip support was added in #19729.

Expected Behavior

Execute permissions should be preserved.

[andrewrk]

To be clear, the expected behavior from the package manager is to ignore permissions from the zip file and set the execute bit based on ELF header and shebang line alone (see #17463). I set the milestone to 0.14.0 in case that is not implemented correctly.

As for implementing extensions in the standard library, that's a separate issue.

[owenbrooks]

For MacOS, that zig-protobuf project downloads the protoc binary in Mach-O file format, so it doesn't get set to executable. Is it worth adding Mach-O header detection to the isExecutable check in addition to ELF and shebang?

[fabioarnold]

Is it worth adding Mach-O header detection to the isExecutable check in addition to ELF and shebang?

I opened a PR here: #21555

[mlafeldt]

@fabioarnold I was excited about this change and tried it with Zig 0.14.0. However, it seems that I'm holding it wrong.

.duckdb_cli_1_2_1 = .{
    .url = "https://github.com/duckdb/duckdb/releases/download/v1.2.1/duckdb_cli-osx-universal.zip",
    .hash = "N-V-__8AAKDAHwa3isStyx3RY4D3NzBMIEdXJyQsBB67L4AG",
    .lazy = true,
},

const duckdb_cli = b.lazyDependency("duckdb_cli_1_2_1", .{}) orelse return;
const cmd = Step.Run.create(b, "duckdb shell");
cmd.addFileArg(duckdb_cli.path("duckdb"));

Gives me:

error: failed to spawn and capture stdio from /Users/mathias/.cache/zig/p/N-V-__8AAKDAHwa3isStyx3RY4D3NzBMIEdXJyQsBB67L4AG/duckdb: AccessDenied

The binary is Mach-O:

❯ file /Users/mathias/.cache/zig/p/N-V-__8AAKDAHwa3isStyx3RY4D3NzBMIEdXJyQsBB67L4AG/duckdb
/Users/mathias/.cache/zig/p/N-V-__8AAKDAHwa3isStyx3RY4D3NzBMIEdXJyQsBB67L4AG/duckdb: Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64]
/Users/mathias/.cache/zig/p/N-V-__8AAKDAHwa3isStyx3RY4D3NzBMIEdXJyQsBB67L4AG/duckdb (for architecture x86_64):  Mach-O 64-bit executable x86_64
/Users/mathias/.cache/zig/p/N-V-__8AAKDAHwa3isStyx3RY4D3NzBMIEdXJyQsBB67L4AG/duckdb (for architecture arm64):   Mach-O 64-bit executable arm64

But it wasn't made executable:

❯ ls -lh /Users/mathias/.cache/zig/p/N-V-__8AAKDAHwa3isStyx3RY4D3NzBMIEdXJyQsBB67L4AG/duckdb
-rw-r--r--@ 1 mathias  staff    98M Mar 10 18:29 /Users/mathias/.cache/zig/p/N-V-__8AAKDAHwa3isStyx3RY4D3NzBMIEdXJyQsBB67L4AG/duckdb

Expected outcome:

❯ chmod +x /Users/mathias/.cache/zig/p/N-V-__8AAKDAHwa3isStyx3RY4D3NzBMIEdXJyQsBB67L4AG/duckdb

❯ /Users/mathias/.cache/zig/p/N-V-__8AAKDAHwa3isStyx3RY4D3NzBMIEdXJyQsBB67L4AG/duckdb
-- Loading resources from /Users/mathias/.duckdbrc
v1.2.1 8e52ec4395
Enter ".help" for usage hints.
Connected to a transient in-memory database.
Use ".open FILENAME" to reopen on a persistent database.
🟡◗ 

Any idea what the problem might be?

[mlafeldt]

Could this be an endianess problem?

❯ xxd /Users/mathias/.cache/zig/p/N-V-__8AAKDAHwa3isStyx3RY4D3NzBMIEdXJyQsBB67L4AG/duckdb | head -n1
00000000: cafe babe 0000 0002 0100 0007 0000 0003  ................

This seems to match FAT_CIGAM but not FAT_MAGIC, but I might be wrong based on how readInt actually works.

---

Update: This seems to be the root cause indeed.

I wrote a small program that checks the result of https://github.com/ziglang/zig/blob/0.14.0/src/Package/Fetch.zig#L1849-L1853 on my M1 Pro. It won't be true unless I add another condition: magic_number == std.macho.FAT_CIGAM.

(I find this strange given that readInt takes endianess into account.)

[owenbrooks]

This is because the point of the CIGAM constants is to detect when the endianness of the encoded file does not match the host endianness. See https://stackoverflow.com/a/44591490

So Fetch.zig should also check the CIGAM constants.

[mlafeldt]

@owenbrooks Yeah, thanks. Opened a new PR: #23193