64-bit .exe installer for windows has wrong default directory

[Diggsey]

The .exe installer tries to install to "C:\Program Files (x86)\Rust", even though it's the 64-bit version. It then fails to create the destination directory due to a permission error.

The .msi installer correctly defaults to "C:\Program Files\Rust ", and has no problems with permissions, I would expect the .exe installer to have the same behaviour.

[alexchandel]

Rust should install to C:\tools\, just like Ant, Python, and many others. C:\tools\ is the place for developer tools that have a known folder. C:\Program Files\ is badly named (compare to C:\ProgramData\), poorly suited for command line tools, and clutters the already hideous PATH more than C:\tools\.

[steveklabnik]

/cc @brson

[Diggsey]

Rust should install to C:\tools, just like Ant, Python, and many others.

Neither Ant nor Python install to C:\tools\ by default, and searching I can't find any reference to C:\tools\ even being a thing? Both Python and Ant install to C:\Python and C:\ant, which is incredibly annoying, so please don't do that!

[alexchandel]

@Diggsey I might be mistaken, but installing both through chocolatey stuck them in C:/tools/ for me. I'd recommend anyone with a machine running Vista or later use chocolatey. And there's a trend in chocolatey to have packages extract to C:/tools/ when they aren't self-contained enough for C:/ProgramData/chocolatey/lib/.

[alexchandel]

For an OS without much filesystem hierarchy, C:\tools\ is a decent place for developer and command-line packages, similar to /opt on some unices. But I'd much rather see a chocolatey package for Rust that actually obeyed chocolatey's conventions and extracted an archive to C:\ProgramData\chocolatey\lib\rust\, with no installer/registry involvement. But Rust only provides msi and exe installers for windows. :\

And all packages that do this reduce PATH clutter, since chocolatey symlinks their executables into C:\ProgramData\chocolatey\bin\.

[vadimcn]

The idea was to deprecate the .exe installer once .msi is known to be working satisfactory.

[alexchandel]

@vadimcn Can we have a zip release too, that contains Rust and Cargo like the others? Linux and OS X have an archive release. Those are preferred in chocolatey because they don't involve the registry or any other Windows components.

[brson]

@alexchandel We do produce tarballs for windows.

[brson]

Seems like we should probably just stop producing the .exe's. That fix would go in https://github.com/rust-lang/rust-packaging.

[alexchandel]

@brson I don't see a cargo+rustc nightly tarball for windows, although I do see ones for linux and osx.

[steveklabnik]

triage: We do not link to the .exe installer anymore, but we still produce them. I don't have access to windows at the moment to check if this bug has been resolved, but it's been a long time...

[alexchandel]

Grabbing the Windows download link from downloads and swapping the .msi for .tar.gz yields a functional link to the tarball, which is nice.

Testing on win7-x64, the MSI extracts with lessmsi, but the directory structure is somewhat unusual so there's no one-liner to get the Rust folder out. The best I came up with was:

lessmsi x rust-foo.msi \opt\ && move \opt\SourceDir\Rust \opt\rust && rmdir /s /q \opt\SourceDir

This yields a Rust install rooted at \opt\rust.

However now that rustup.rs exists, multiple targets aren't really an issue anymore. Someone should make a Chocolatey package for rustup.rs...

[Mark-Simulacrum]

Can someone with access to Windows check what happens here today?

[Diggsey]

@Mark-Simulacrum The latest version installs to C:\Rust instead, which works, but is a terrible default.

[steveklabnik]

Triage:

This seems... fine. I'm not sure if this should stay open or not; I'll let the relevant team (infra? compiler?) decide.