[release/9.0-staging] Fix UNC paths#111499
Conversation
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 <elfung@microsoft.com>
Co-authored-by: Elinor Fung <elfung@microsoft.com>
|
Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov |
jeffschwMSFT
left a comment
There was a problem hiding this comment.
lgtm. please get a code review. we will take for consideration in 9.0.x
|
@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.