[release/6.0-preview6] [FileStream] handle UNC and device paths

[github-actions]

Backport of #54483 to release/6.0-preview6

/cc @adamsitnik

Customer Impact

FileStream can 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 CreateFileW to NtCreateFile), which was the source of the problems.

[dotnet-issue-labeler]

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]

cc @safern

[ghost]

Tagging subscribers to this area: @dotnet/area-system-io
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Backport of #54483 to release/6.0-preview6

/cc @adamsitnik

Customer Impact

FileStream can 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 CreateFileW to NtCreateFile), which was the source of the problems.

Author:	github-actions[bot]
Assignees:	-
Labels:	area-System.IO
Milestone:	6.0.0

[danmoseley]

This got missed as we didn't label it for tactics.
@stephentoub could you sign off maybe? This seems fairly critical to port.

[danmoseley]

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]

Matches original change.

[BruceForstall]

@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.