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

`cargo uninstall` tries to delete executables that are running, which fails on Windows #3364

FaultyRAM opened this issue Dec 3, 2016 · 3 comments


Copy link

@FaultyRAM FaultyRAM commented Dec 3, 2016

cargo uninstall doesn't take into account that the crate being uninstalled may in fact be running, and that attempting to delete such an executable will fail on Windows. Because removing the binary is the last step in the uninstall process, this leads to a phenonemon I dub "Schrödinger's crate", in which a crate is both installed and uninstalled; the executable still exists, so cargo install fails, but all installation metadata is gone, so cargo uninstall fails!

One way to cause this is via the Rusty Code plugin for VS Code; it depends on Racer, which can be installed via cargo install and is active while Rusty Code is active. Trying to cargo uninstall Racer in this situation leads to breakage as described above.

You can work around this by deleting the leftover executable after making sure it isn't running; cargo install --force also works.

Tested with the latest nightly Rust, installed via rustup-rs:

rustc 1.15.0-nightly (908dba0c9 2016-12-01)
binary: rustc
commit-hash: 908dba0c9477b7dd022a236cb1514ddfca9369f2
commit-date: 2016-12-01
host: x86_64-pc-windows-msvc
release: 1.15.0-nightly
LLVM version: 3.9
cargo 0.16.0-nightly (3568be9 2016-11-26)

This comment has been minimized.

Copy link

@alexcrichton alexcrichton commented Dec 8, 2016

Hm so cargo install in theory is transactional in the sense that if it fails Cargo's still not in a "corrupt" state. Have you found though that after a failed cargo uninstall it's essentially in a corrupt state?


This comment has been minimized.

Copy link

@FaultyRAM FaultyRAM commented Dec 8, 2016

In this case no, at least as far as I can tell. The crate isn't listed in .crates.toml, and once the leftover executable is dealt with everything works as normal. It really does seem to be just that the executables get left behind.

@alexcrichton alexcrichton added A-errors C-bug and removed A-errors labels Dec 9, 2016

This comment has been minimized.

Copy link

@alexcrichton alexcrichton commented Dec 9, 2016

Sounds bad! If cargo uninstall fails Cargo should always leave everything in a consistent state.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.