rustup fails with symlink RUSTUP_HOME/toolchains #3737
Comments
|
BTW: This bug leaves you with a state where you can't do anything with rustup, no update, no compile of any crate (e.g. rustup itself) to debug. |
|
@jo-so Okay, I'll keep both issues open but those two issues do seem related. Unfortunately since this is caused by self-referential symlinks (created presumably in another I'll find some time to investigate into both issues. |
|
Here's a git-bisect run. A good version was 1.25.0, and the culprit is 2c9297d. |
It's not about self-referential symlinks. As you can see in the With a self compiled version you get Which points to Lines 45 to 54 in 0c501d5 contrary to rustup/src/toolchain/toolchain.rs Lines 70 to 74 in 0c501d5 |
|
@jo-so Wow, many thanks for your help with the investigation! It's true that with I have no idea why this option flag is enabled though, and this patch was included before I was even there. Maybe @rbtcollins can provide more context on this one? Considering the Windows side of the same function, it doesn't seem to have the same semantics: Lines 40 to 43 in 0c501d5
OTOH the only caller of this function is |
Fixes #3737. ## Concerns - [ ] Testing: can we bake a smoke test to prevent regression?
|
@Joso I just did some more research on this one. The snippet that you mentioned above actually came from fn open_dir(p: &Path) -> io::Result<fs::File> {
let mut options = OpenOptions::new();
options.read(true);
options.custom_flags(libc::O_NOFOLLOW);
options.open(p)
}For the reference, fn open_dir(p: &Path) -> Result<File> {
let mut options = OpenOptions::new();
options.read(true);
options.custom_flags(FILE_FLAG_BACKUP_SEMANTICS | FILE_FLAG_OPEN_REPARSE_POINT);
let maybe_dir = options.open(p)?;
if maybe_dir.metadata()?.is_symlink() {
return Err(io::Error::new(
io::ErrorKind::Other,
"Path is a directory link, not directory",
));
}
Ok(maybe_dir)
} |
|
Indeed thanks for the bug. @rami3l I think what we need here for .rustup/toolchains and .rustup/downloads, but not for directories in general, are the following semantics:
I think remove_dir_all + the fs_at crates should permit solving this quite nicely. re remove_dir_all behaviour, see https://docs.rs/remove_dir_all/0.8.2/remove_dir_all/ the last two paragraphs before 'features'. tl;dr symlinks are not directories, and if you're dealing with a symlink, just unlink, don't expect remove_dir_all to delete it. re: the semantics on windows, the implementation details are different, but roughly identical semantics are achievable - the open with FILE_FLAG_BACKUP_SEMANTICS is required to read the link out of a link, compared to linux where a different syscall is used to read links. Happy to review a patch. |
|
Is there a workaround that isn't "copy my 23Gigabyte toolchains directory somewhere the backups will pick itup"? Currently I am in this state:
IOW for me this is a very severe regression. |
Answering my own question: I was able to get things to work by replacing the symlink and using a bind mount. This is obviously not a long-term solution. Is there a way I can downgrade my rustup to a non-broken version and prevent it from re-updating itself? |
This gave me a working rustc but rustup is nonfunctional: This is because my |
Yes. To downgrade, download an older version of rustup-init from the dist server https://static.rust-lang.org/rustup and run it to install it. the env variable RUSTUP_UPDATE_ROOT will override that, so if you set it to an empty web host in your environment, rustup will no longer be able to self-update. Or, you can pass --no-self-update to rustup when you invoke an update / install. If you're using an IDE that invokes rustup, consult its documentation. |
|
I tried to follow these instructions. This is FYI and for the information of anyone else with similar troubles.
I was not able to do this because I don't know the precise URL for "an older version of rustup-init", and that server doesn't do directory listings.
This doesn't work because rustup bails out on getting a 404 response.
This doesn't work I have worked around things a different way. |
|
@jo-so @ijackson A new beta release is available, would you mind trying it out? |
|
It works: |
|
Thanks! Yes, this worked for me. First, using my existing rustup, but with that rune, and a troublesome symlink at And, now that it has updated itself: |
Problem
BTW: This message isn't very helpful.
I'm having a symlink at ~/.rustup/toolchains pointing to ~/.cache/rustup/toolchains
Steps
mkdir ~/rustup-test && cd ~/.rustup && cp -r downloads tmp update-hashes settings.toml ~/rustup-testln -s ~/.rustup/toolchains ~/rustup-test/RUSTUP_HOME=$HOME/rustup-test rustup updatePossible Solution(s)
No response
Notes
This happens since the update from
to
Rustup version
Installed toolchains
The text was updated successfully, but these errors were encountered: