rustup override handles symlinks to directories poorly

While in most other contexts, treating symlinks to directories as directories makes sense, I don't think it does in rustup override:

You can't cd into a symlink and then have rustup recognize the override, even though the symlink is in $PATH.
When using rustup override list, symlinks to directories are shown as regular, and are not removed with rustup override unset --nonexistent.
When using rustup override unset --path the_symlink, rustup will instead remove the override at the target of the symlink! If you set an override on a project, then rename the project and symlink the old location to the new directory, it's not possible via rustup to remove the old override - and trying to do so will actually remove the override for the new directory!

I feel like having either 1. or 2. working well would be alright, but 3. should probably be addressed regardless.

Thoughts?

Example:

daboross:/home/daboross/
$ rustup override list
no overrides
daboross:/home/daboross/
$ mkdir test1
daboross:/home/daboross/
$ cd test1
daboross:/home/daboross/test1/
$ rustup override set nightly
info: using existing install for 'nightly-x86_64-unknown-linux-gnu'
info: override toolchain for '/home/daboross/test1' set to 'nightly-x86_64-unknown-linux-gnu'

  nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.19.0-nightly (28fd1e519 2017-05-27)

daboross:/home/daboross/test1/
$ cd ../
daboross:/home/daboross/
$ mv test1 test2
daboross:/home/daboross/
$ ln -s test2 test1
daboross:/home/daboross/
$ rustup override list
/home/daboross/test1                    	nightly-x86_64-unknown-linux-gnu
daboross:/home/daboross/
$ cd test2
daboross:/home/daboross/test2/
$ rustup override set nightly
info: using existing install for 'nightly-x86_64-unknown-linux-gnu'
info: override toolchain for '/home/daboross/test2' set to 'nightly-x86_64-unknown-linux-gnu'

  nightly-x86_64-unknown-linux-gnu unchanged - rustc 1.19.0-nightly (28fd1e519 2017-05-27)

daboross:/home/daboross/test2/
$ rustup override unset --path ../test1
info: override toolchain for '../test1' removed
daboross:/home/daboross/test2/
$ rustup override list
/home/daboross/test1                    	nightly-x86_64-unknown-linux-gnu
daboross:/home/daboross/test2/
$ cd ../test1
daboross:/home/daboross/test1/
$ rustc --version
rustc 1.17.0 (56124baa9 2017-04-24)
daboross:/home/daboross/test1/
$

As you can see, rustup clearly says override toolchain for '../test1' removed, while it actually removed the toolchain for test2.

In addition, even though $PATH is showing test1 in the last command, the override does not take affect and rustc is still stable (the default). If ignoring all overrides for symlinks is the intended behavior, directory symlinks should probably be shown as "not a directory" in rustup override list.

@daboross

Hi @daboross

Are you still interested in having this kind of setup supported better by rustup?

If so, I could do with a set of specific use-cases and how you would expect them to behave, so that I can set up some tests and work out what needs to be handled. If not, you can just close this issue since noone else has chimed in as being interested yet.

D.

Sounds good!

The most pressing issue is particularly if an override is created for a directory, and then the directory is turned into a symlink, there is no way to remove the override.

The following commands should create and remove an override:

mkdir dir1 dir2
cd dir2
rustup override set stable
cd ../
rmdir dir2
ln -s dir1 dir2
cd dir2
rustup override list
rustup override remove --path $PWD/dir2
rustup override remove --nonexistent

Currently, the above script outputs:

info: using existing install for 'stable-x86_64-unknown-linux-gnu'
info: override toolchain for '/home/daboross/testdir/dir2' set to 'stable-x86_64-unknown-linux-gnu'

  stable-x86_64-unknown-linux-gnu unchanged - rustc 1.38.0 (625451e37 2019-09-23)

/home/daboross/testdir/dir2                    stable-x86_64-unknown-linux-gnu
info: no override toolchain for '/home/daboross/asdfasdf/dir2'
info: no nonexistent paths detected

Ideally, rustup remove --path $PWD/dir2 should find and remove the override set for dir2, and if that is not run, rustup remove --nonexistent should also remove the override, as there is no directory present at $PWD/dir2

Notably, remove --nonexistent removes overrides set on files. If I run touch dir2 instead of ln -s dir1 dir2, then remove --nonexistent correctly removes it. But it won't remove a symlink, even though that symlink is equally unusable as an override.

In addition, it would be nice if the output for override list in the above set of commands should include (not a directory), or perhaps (unusable symlink):

/home/daboross/asdfasdf/dir2 (not a directory)  stable-x86_64-unknown-linux-gnu

Rather than:

/home/daboross/testdir/dir2                    stable-x86_64-unknown-linux-gnu

The original issue included wanting cding into a symlink to work, but I don't really need that behavior. As long as the ability to remove overrides set on symlinks is present, I'm good with that.

Thank you for that excellent description. From there I'm sure either I or someone else can come up with a test case and thence some useful fixes.

WIP: stage is_symlink flag in override_remove of rustup_mode.rs

fix(settings): remove overrides set on a path before it became a symlink