[release/6.0-preview6] [FileStream] handle UNC and device paths #54595
Conversation
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
|
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
|
cc @safern |
|
Tagging subscribers to this area: @dotnet/area-system-io Issue DetailsBackport of #54483 to release/6.0-preview6 /cc @adamsitnik Customer Impact
TestingI've verified locally that the UNC and device paths work fine now. I've also added tests to ensure that this bug is never coming back #54545. RiskThe risk is low as we have basically switched back to higher level syscall (what we were doing for .NET 5) that does not require us to handle the DOS to NT paths mapping on our own (from
|
|
This got missed as we didn't label it for tactics. |
|
I'm satisfied that the test failures are unrelated. @BruceForstall there are several JIT jobs that failed here (crash?) leaving no log. Is the missing log issue something we know about? https://dev.azure.com/dnceng/public/_build/results?buildId=1201218&view=ms.vss-test-web.build-test-results-tab&runId=35979858&paneView=debug&resultId=102659 |
danmoseley
added
Servicing-approved
|
@danmoseley Yes, that looks like the same windows arm64 issue we've seen lately. A Helix rollout to fix that should have happened this morning, I believe. |
ghost
locked as resolved and limited conversation to collaborators
Backport of #54483 to release/6.0-preview6
/cc @adamsitnik
Customer Impact
FileStreamcan not open files located on network shares (UNC paths starting with//or\\) and Windows devices (paths starting with\\.\). This is a regression from previous release that impacted many customers (#54337, #54474, #54475) including the WinForms Team (cc @Lydia-Shi).Testing
I've verified locally that the UNC and device paths work fine now. I've also added tests to ensure that this bug is never coming back #54545.
Risk
The risk is low as we have basically switched back to higher level syscall (what we were doing for .NET 5) that does not require us to handle the DOS to NT paths mapping on our own (from
CreateFileWtoNtCreateFile), which was the source of the problems.