When `rustup self uninstall` is invoked from inside WSL, it leaves some files behind

Problem

As described in this related bug, I have a daily-driver system configuration where I run Windows 10, I use WSL Bash as my shell for daily-driver shell operations (such as running git), and I have a Windows version of Rust installed. When I want to do a Rust operation I type out "cargo.exe" "rustup.exe" etc. WSL as a project works very hard to ensure Windows applications invoked from a WSL shell in this manner behave normally when invoked this way, and indeed the Rust toolchain has always behaved normally for me invoked this way. Cargo.exe works fine. Rustup.exe works fine when upgrading cargo and rustc.

The rustup self operations however appear to behave incorrectly when invoked from WSL Bash. In addition to #3331 linked above, rustup self uninstall reproducibly misbehaves when invoked from WSL in a way it does not when invoked from regular Windows CMD.EXE.

Steps

I am running Windows 10 , 10.0.19045 Build 19045. I have a Windows Services for Linux install (WSL1 VM, Ubuntu 20.04.6 LTS). My $WSLENV environment variable inside WSL is normal (WT_SESSION::WT_PROFILE_ID).

I run rustup.exe self uninstall (from inside CMD.EXE) and restart. I open a new shell and verify there is no .cargo or .rustup in my Windows home dir. I believe at this point my Win10 install can be considered "clean" (IE same as a fresh new install).

I run a rustup.init I downloaded from https://static.rust-lang.org/rustup/archive/1.25.1/x86_64-pc-windows-msvc/rustup-init.exe. I run a regular installation. I reboot the computer again.

On my new bootup, I open terminal.app and enter a WSL Bash shell. I run:

Andi@Alita:/mnt/c/Users/Andi$ rustup.exe self uninstall


Thanks for hacking in Rust!

This will uninstall all Rust toolchains and data, and remove
%USERPROFILE%\.cargo/bin from your PATH environment variable.

Continue? (y/N) y

info: removing rustup home
info: removing cargo home
info: removing rustup binaries
info: rustup is uninstalled

The self uninstall reported itself as successful. I check to see if .cargo and .rustup were actually uninstalled.

Andi@Alita:/mnt/c/Users/Andi$ find .cargo
.cargo
.cargo/bin
.cargo/bin/cargo-clippy.exe
.cargo/bin/cargo-fmt.exe
.cargo/bin/cargo-miri.exe
.cargo/bin/cargo.exe
.cargo/bin/clippy-driver.exe
.cargo/bin/rls.exe
.cargo/bin/rust-gdb.exe
.cargo/bin/rust-gdbgui.exe
.cargo/bin/rust-lldb.exe
.cargo/bin/rustc.exe
.cargo/bin/rustdoc.exe
.cargo/bin/rustfmt.exe
.cargo/bin/rustup.exe

They're still there. They are visible from both CMD.EXE and from Bash.

Although I ran this test with Rustup 1.25.1, I previously saw it with Rustup 1.25.2. In between these two tests, I tried installing Rustup 1.25.1, restarting, then uninstalling from inside of a CMD.EXE window. When I invoked rustup self uninstall from CMD.EXE, I saw the expected behavior (everything uninstalled).

Possible Solution(s)

As stated in the other bug, my "expected behavior" is that Windows rustup.exe should behave the same when run from an ordinary WSL Bash prompt as it does when run from an ordinary CMD.EXE prompt. Although my mixed windows/wsl configuration is somewhat unusual, I do not believe it is a rare one. What is especially problematic to me about the current behavior is it "fails silently" (it claims to have succeeded, but did not).

Notes

No response

Rustup version

Cannot answer (because I have uninstalled rustup) but it was 1.25.1

Installed toolchains

Cannot answer (because I have uninstalled rustup) but I believe it was 1.69.0 x86_64 msvc (I would have noticed if it were not)

Start by reproducing rustup.exe self uninstall from WSL Bash and comparing it with the same command from CMD.EXE, using the Windows 10 and WSL1 setup described. Check whether the reported .cargo/bin files remain after the command reports success. Done means the uninstall behaves consistently and removes the files, or clearly reports why it cannot.