Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Nightly Windows tarballs may not be installable on Unix #42121

Closed
alexcrichton opened this issue May 20, 2017 · 5 comments · Fixed by #42343
Closed

Nightly Windows tarballs may not be installable on Unix #42121

alexcrichton opened this issue May 20, 2017 · 5 comments · Fixed by #42343

Comments

@alexcrichton
Copy link
Member

I got two errors in a project of mine for recent nightlies which I think are releated to the rustification of rust-installer but I'm not 100% certain:

@cuviper does this sound familiar to you?

@alexcrichton
Copy link
Member Author

Oh looks like rust-lang/rust-installer#65 and rust-lang/rustup#1127 are all related to this as well.

@cuviper
Copy link
Member

cuviper commented May 20, 2017

Ah, yes, backslashes in the manifest are an easily understood problem.

Executable install.sh is harder. At least I left a note about that here. :) Since Windows doesn't really have such flags, I suspect it must have worked on some MSYS tricks with ACLs before. Maybe we should make a special case for this when writing the tarball, like writing known-executable file names with manually-tweaked metadata?

@alexcrichton
Copy link
Member Author

Yeah I think we'll probably just want to special case everything going into the tarballs and manually set the metadata for the various bits and pieces. I'm... not entirely sure how this worked with MSYS, but presumably there's some weird translation layer which we're not aware of and isn't surfaced through winapi things...

@cuviper
Copy link
Member

cuviper commented May 21, 2017

OK, so #42132 should fix up the manifests at least.

Researching the file modes, I first wondered whether the tar crate should read the advanced ACLs for FILE_EXECUTE, as right now it just approximates the mode. But it looks like all created files have "execute" privileges anyway -- e.g. even icacls manifest.in includes Everyone:(RX). You can remove that with chmod in MSYS/Cygwin/etc., but it appears atypical for a file not to be executable.

The good news is that tar also doesn't care about execute when unpacking on Windows, just checking for readonly. The rest will follow the defaults of File::create, still with executable ACLs. So I think the permissions created by rustup will be fine, but I guess if one manually unpacks with MSYS/Cygwin tar they may get non-executable rustc.exe etc.

@alexcrichton The quickest hack for you would be to just change this:

Step 7 : RUN /tmp/rust-mingw-nightly-i686-pc-windows-gnu/install.sh --prefix=`rustc --print sysroot`

... to invoke sh install.sh instead, which doesn't care about execute privileges. :)

bors added a commit that referenced this issue May 21, 2017
Update rust-installer to normalize manifest paths

This fixes the backslash-paths found in the manifests of installers that are built on Windows.  This is the most problematic part of #42121, leaving just the non-executable install.sh.

r? @alexcrichton
@alexcrichton
Copy link
Member Author

Ah yeah I don't think there's a great way to flag a file on Windows as executable/not-executable, I'm basically just thinking that we have a whitelist of files/patterns that will get listed as executable in the tarball (as the tarball stores unix modes) and we'd just follow that.

cuviper added a commit to cuviper/rust that referenced this issue Jun 1, 2017
It now marks a few whitelisted extensions as executable in the tarball,
so Windows packages can be extracted on other platforms and directly
execute install.sh.

It also includes a fix for the chmod on bulk dirs, so now the html docs
won't be marked executable en masse.

Fixes rust-lang#42121
r? @alexcrichton
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue Jun 1, 2017
…crichton

Update rust-installer for Windows executable mode

It now marks a few whitelisted extensions as executable in the tarball,
so Windows packages can be extracted on other platforms and directly
execute install.sh.

It also includes a fix for the chmod on bulk dirs, so now the html docs
won't be marked executable en masse.

Fixes rust-lang#42121
r? @alexcrichton
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue Jun 1, 2017
…crichton

Update rust-installer for Windows executable mode

It now marks a few whitelisted extensions as executable in the tarball,
so Windows packages can be extracted on other platforms and directly
execute install.sh.

It also includes a fix for the chmod on bulk dirs, so now the html docs
won't be marked executable en masse.

Fixes rust-lang#42121
r? @alexcrichton
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue Jun 2, 2017
…crichton

Update rust-installer for Windows executable mode

It now marks a few whitelisted extensions as executable in the tarball,
so Windows packages can be extracted on other platforms and directly
execute install.sh.

It also includes a fix for the chmod on bulk dirs, so now the html docs
won't be marked executable en masse.

Fixes rust-lang#42121
r? @alexcrichton
Mark-Simulacrum added a commit to Mark-Simulacrum/rust that referenced this issue Jun 2, 2017
…crichton

Update rust-installer for Windows executable mode

It now marks a few whitelisted extensions as executable in the tarball,
so Windows packages can be extracted on other platforms and directly
execute install.sh.

It also includes a fix for the chmod on bulk dirs, so now the html docs
won't be marked executable en masse.

Fixes rust-lang#42121
r? @alexcrichton
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants