release assets is not a executable file

[axetroy]

$ ls -lh
-rw-r--r--@  1 axetroy  staff    43M 12  8 02:18 deno_osx_x64
-rw-r--r--@  1 axetroy  staff    11M 12  8 02:17 deno_osx_x64.gz
$ ./deno_osx_x64 --version
fish: The file './deno_osx_x64' is not executable by this user
$ chmod +x deno_osx_x64
$ ./deno_osx_x64 --version
deno 0.26.0
$ ls -lh
-rwxr-xr-x@  1 axetroy  staff    43M 12  8 02:18 deno_osx_x64
-rw-r--r--@  1 axetroy  staff    11M 12  8 02:17 deno_osx_x64.gz

[ry]

I'm not sure what error you're experiencing, but it works for me.

~/Downloads> gunzip deno_osx_x64.gz
~/Downloads> ls -lh deno_osx_x64
-rw-r--r--  1 rld  staff    43M Dec  7 15:29 deno_osx_x64
~/Downloads> chmod u+x deno_osx_x64
~/Downloads> ./deno_osx_x64 -V
deno 0.26.0

[hayd]

@ry axetroy expects that the binary would have executable permission after gunzip i.e. chmod wouldn't be necessary.

Since gzip compress/decompress is supposed to retain file permissions this is a little surprising.

[axetroy]

@hayd That is what I mean.

@ry Archive with tar command, then it can retain the permissions of the file.

The tar command is cross-platform, and Windows also supports.

When I developed third-party tools, I needed to decompress deno_linux_x64.gz anddeno_win_x64.zip, I found that their archiving methods are different, and the file permissions are not reserved.

I think using tar command for file archiving is a better option

tar -czf ./target/release/deno_linux_x64.tar.gz ./target/release/deno
tar -czf ./target/release/deno_osx_x64.tar.gz ./target/release/deno
tar -czf ./target/release/deno_win_x64.tar.gz ./target/release/deno.exe

Of course, if apply it, deno_install must also be changed.

[ry]

Yeah - we can switch to tar for all platforms. I agree it’s probably better.

[lucacasonato]

TAR is not supported naively on windows so we should continue shipping zip files for windows. Windows doesnt have an exec bit so tar isn't required to keep that. Maybe we just ship both tar and zip for windows?

[hayd]

It's the -c. For some reason when outputting to stdout it loses the permissions.

https://github.com/denoland/deno/blob/31ddfd5a42d658b92e954e44d3326a8e37ac9198/.github/workflows/ci.yml#L173

If you use the "regular" way: gzip deno_osx_x64 it retains permissions.

---

Edit: which is to say, changing to:

gzip -S "_osx_x64.gz" target/release/deno

should fix this issue.

[ry]

@lucacasonato Oh - yes that's what I thought. I don't use Windows so based on the above comments I thought maybe tar support was added. I'm fine with switching to zip for everyone. It's annoying to have two types of packages.

@hayd How does that work? The permission bits are not in the file contents themselves and I thought .gz files don't encode metadata... I guess I'm wrong about the second assumption.

[hayd]

@ry no idea, but i tested on osx and linux and both seems to retain permissions. #3480.

[MarkTiedemann]

TAR is not supported naively on windows

Not quite true. tar.exe was added in 2018.

https://devblogs.microsoft.com/commandline/tar-and-curl-come-to-windows/

C:\>where tar
C:\Windows\System32\tar.exe

[hayd]

This issue seems to be back for the .gz files. Which makes no sense to me as it looks like nothing has changed since it was fixed. 🤷‍♂