[release/9.0-staging] Fix UNC paths #111499
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
If the input file was a network path then the raw path returned by GetFinalPathByHandle may return a UNC path. If so, and if the original path wasn't a UNC path, and the original path doesn't need normalization, we want to use the original path.
Co-authored-by: Elinor Fung <[email protected]>
Co-authored-by: Elinor Fung <[email protected]>
|
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov |
jeffschwMSFT
added
the
Servicing-consider
jeffschwMSFT
added
Servicing-approved
|
@agocke can you take a look at the CI failures? we can merge when ready. |
|
This will just remove the Long UNC-prefix, when not needed. Should one not expect to see the network-drive-letter, instead of the network-path behind the network-drive-letter? Ex. |
|
/ba-g timeout is unrelated and hitting multiple PRs. |
|
@snakefoot It sounds like your scenario is slightly different. What is the input and output in your case? |
|
I'm just the NLog-project-janitor, and users are having issues when running their NET9-application from a network-drive:
Where System.AppContext.BaseDirectory in NET9 suddenly returns the Long UNC Network-path, instead of the mounted network-drive. Ex. |
Backport of #110033 to release/9.0-staging
/cc @agocke
Customer Impact
This change causes apps which are launched from network shares ("UNC paths" aka \server-name) to have their location shown as extended UNC paths ("\?\UNC\server-name"). This is a regression both because the paths are different from what they were before, but also because some APIs will not accept UNC server paths. This manifests as a breaking change in .NET 9.
Regression
Regression from .NET 8 to .NET 9.
Testing
Tested manually. Unfortunately we do not have a way to test network shares in our CI system.
Risk
Low risk. The change is targeted to one API and only to paths which have extended UNC paths.