Uh oh!
There was an error while loading. Please reload this page.
[release/6.0-preview6] [FileStream] handle UNC and device paths - #54595
Conversation
ghost
commented
Jun 23, 2021
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. |
adamsitnik
commented
Jun 23, 2021
cc @safern |
ghost
commented
Jun 23, 2021
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
|
danmoseley
commented
Jun 25, 2021
This got missed as we didn't label it for tactics. |
danmoseley
commented
Jun 25, 2021
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
left a comment
There was a problem hiding this comment.
Matches original change.
BruceForstall
commented
Jun 25, 2021
@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. |
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.