workspace: Trim prefix canonicalize path for windows

[dovakin0007]

Release Notes:

• N/A

[dovakin0007]

had to trim it cause it was causing issue with powershell
the left one is 0.164 the right side one is the fixed version

[SomeoneToIgnore]

1. This PR has no description so it's not clear why are you doing this
2. It is an error to trim a UNC path over 260 chars long (https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry)
3. This is not the only place where canonicalized paths need better handling, and doing it just here is a hack, not a fix
4. #19727

[SomeoneToIgnore]

Ok, at least we've got a reasoning behind it, great.

Does not seem a right way to go, but does indeed fix a large breakage in the recent Windows builds.
@JunkuiZhang do you have any preferences on what to do with this?

[dovakin0007]

1. This PR has no description so it's not clear why are you doing this 2. It is an error to trim a UNC path over 260 chars long (https://learn.microsoft.com/en-us/windows/win32/fileio/maximum-file-path-limitation?tabs=registry) 3. This is not the only place where canonicalized paths need better handling, and doing it just here is a hack, not a fix 4. #19727

yeah this is hack for now cause it does causes issues while running with build.rs it didn't happen 0.161 and I understand canonicalized does need a overhaul for windows

[JunkuiZhang]

Does not seem a right way to go, but does indeed fix a large breakage in the recent Windows builds.

Seems so.

do you have any preferences on what to do with this?

I was wondering if there’s a chance we could move forward with #19727? Otherwise, we might end up needing more and more hackings like this PR in the future.

I’m not sure how to express this perfectly in English, but based on the current changes in #19727, I feel it minimizes the scope of modifications as much as possible. Strictly speaking, #19727 only ensures that any paths entering Zed are sanitized. However, its potential limitation is that it doesn’t guarantee the paths interacting with these sanitized paths are also sanitized (this is explained in more detail in #19727).

To address this further, we might need to make more extensive changes, similar to what was done in #19228.

[SomeoneToIgnore]

I fully agree to move on with the minimum surface sanitized approach you have (fixing potentially missed places later), just was not sure what is needed to move it forward, esp. after @ConradIrwin brought more ideas into the discussion in another PR.

Since Windows builds are badly broken right now (my opinion), I feel that anything that does not look like a bad hack (as here) is a good start already.

Let me gather my thoughts on Monday and consider the merge.

Meanwhile, would be great to get comment with a recap on what's left to push that draft sanitization PR to completion.

[JunkuiZhang]

I fully agree to move on with the minimum surface sanitized approach you have (fixing potentially missed places later), just was not sure what is needed to move it forward, esp. after @ConradIrwin brought more ideas into the discussion in another PR.

Since Windows builds are badly broken right now (my opinion), I feel that anything that does not look like a bad hack (as here) is a good start already.

I see, this PR looks good to me.

Let me gather my thoughts on Monday and consider the merge.

Thanks for your efforts on pushing Windows forward!

Meanwhile, would be great to get comment with a recap on what's left to push that draft sanitization PR to completion.

I’ll add comments in #19727 tomorrow.

[SomeoneToIgnore]

We can always get back to this after considering #19727