fix: avoid resolving symlinks on windows trampoline

[ruben-arts]

Description

Avoid resolving symlinks on windows in a trampoline binary.

Trampolines are being build in: https://github.com/prefix-dev/pixi/actions/runs/24658245390 Afterwards I merged them into this branch.

Fixes #5923

How Has This Been Tested?

I wasn't able to reproduce the issue described in #5923 but after discussing with @wolfv it does make sense to use to avoid this behavior on Windows.

Checklist:

• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas

[baszalmstra]

I think we should use https://docs.rs/dunce/latest/dunce/fn.simplified.html instead on windows.

[ruben-arts]

I think we should use docs.rs/dunce/latest/dunce/fn.simplified.html instead on windows.

Now I just remove the line from windows. Do you think it has value to change it to dunce?

[baszalmstra]

I assume the canonicalize was there for a reason? I agree that resolving symlinks doesnt seem required.

I read a bit more about this, we can also use https://doc.rust-lang.org/std/path/fn.absolute.html that wont resolve symlinks but should at least absolutize the path?

[ruben-arts]

It was there from this PR: #5773
To support symlinked trampolines, it's meant to resolve the symlinks on linux and mac but on windows we might not want to bother.

[baszalmstra]

Why not for windows? Symlinks are also supported there?

Ok reading this more carefully now.

The code currently resolves all symlinks. Then it reads the configuration next to the resolved executable. This ensures that if you symlink a binary that it can properly find the configuration next to the original binary (instead of next to the symlink).

Ah but as described in the issue env::current_exe() already returns the canonical executable on windows. So the right solution is indeed to simply not canonicalize on Windows.

Sorry for the noise! Lets make sure to add a comment though!

[ruben-arts]

@baszalmstra Thanks for the in-depth review!