Maintain broken symlink behaviour for the Windows exe resolver

[ChrisDenton]

When the resolver was updated to remove the current directory from the search path (see #87704), care was take to avoid unintentional changes that hadn't been discussed. However, I missed the broken symlink behaviour. This PR fixes that.

Edit This turned out to be more important than I first realised. There are some types of application stubs that will redirect to the actual process when run using CreateProcessW, but due to the way they're implemented they cannot be opened normally using a File::open that follows reparse points. So this doesn't work with our current exists and try_exists methods.

Fixes #91177

[rust-highfive]

r? @m-ou-se

(rust-highfive has picked a reviewer for you, use r? to override)

[bors]

☔ The latest upstream changes (presumably #92201) made this pull request unmergeable. Please resolve the merge conflicts.

[ChrisDenton]

@m-ou-se I've rebased and greatly simplified this PR. This turned out to be more important than I first realised so it'd be great if this could be merged reasonably quickly. Maybe even beta backported if that's an option.

There are some types of application stubs that will redirect to the actual process when run using CreateProcessW, but due to the way they're implemented they cannot be opened normally using a File::open that follows reparse points. So this breaks our current exists and try_exists methods.

[m-ou-se]

Sorry for the delay.

@bors r+

Maybe even beta backported if that's an option.

It's a bit late for that, as beta is splitting off in a day or two.

Do you have an example of a situation that's broken and fixed by this PR? Did you or anyone else run into that issue?

[bors]

📌 Commit 9a7a8b9 has been approved by m-ou-se

[ChrisDenton]

Sorry for the delay.

No problem, I realise I was very last minute.

Do you have an example of a situation that's broken and fixed by this PR? Did you or anyone else run into that issue?

Yeah, this was an issue I ran into when testing something else. Basically when the Windows Store installs a command line application, it uses a special kind of proxy file. These applications cannot be found using Rust 1.58 (edit: they can be run using an absolute path though).

The reason is that the file has a "reparse tag" (i.e. link metadata) but the usual CreateFileW doesn't understand how to follow that link. CreateProcessW does however.

[ChrisDenton]

I mean, nobody has reported an issue through all the time it spent in nightly, beta then stable. So it's not a common situation. It would be frustrating however if someone does encounter it because it may not be obvious what went wrong.

So I don't think this is absolutely urgent but I do think it's important enough to be rolled into a release whenever the next opportunity happens to be.

[Mark-Simulacrum]

@bors p=1

[bors]

⌛ Testing commit 9a7a8b9 with merge 2ff7ea4...

[bors]

☀️ Test successful - checks-actions
Approved by: m-ou-se
Pushing 2ff7ea4 to master...

[rust-timer]

Finished benchmarking commit (2ff7ea4): comparison url.

Summary: This benchmark run did not return any relevant results. 8 results were found to be statistically significant but too small to be relevant.

If you disagree with this performance assessment, please file an issue in rust-lang/rustc-perf.

@rustbot label: -perf-regression