Description
Both locally and on CI. It has been broken for some time, we've just not noticed (since before 1.13, and on various versions of Rust). I'm not sure if this is an old regression in Rustup or due to a change in std or even Mac OS.
The test checks that Rustup can successfully uninstall itself. The test process creates some directories and sets up an environment (including the cargo_home directory, which is something like target/tests/rustup-cargo/ch). It then runs rustup-init to install Rustup, then rustup self uninstall -y to uninstall it. As part of that, the Rustup process tries to delete target/tests/rustup-cargo/ch and a bunch of other files and directories. Note that the Rustup executable is target/tests/rustup-cargo/ch/bin/rustup. Deleting most of these files and directories (including target/tests/rustup-cargo/ch/bin) works fine. But attempting to delete target/tests/rustup-cargo/ch fails with ENOENT - directory does not exist. I have verified that it does in fact exist. It ends up being removed by the test process after the test finishes (and fails because it can't delete the directory).
Trying to delete the directory anywhere in the Rustup process fails (I tried using different ways to delete it in (i.e., not just remove_dir_all) lots of different places. Deleting it in the test process works fine. Therefore, I think there is some kind of lock on that directory by the test process. Nothing I could do in Rust fixed this (trying to prevent any possible way of keeping the directory open). DTrace and Fuser told me nothing useful, permissions on the directory are fine. I don't know enough about Mac OS to investigate any further :-(
Given that this seems to be a bug due to the test architecture and not a bug in real life, we'll ignore this test on Mac OS. However, it would be great to find out what is going on here, and/or rewrite the test some how so that it works.