Return correct casing of filesystem path during normalization

[SteveL-MSFT]

PR Summary

On a case-insensitive filesystem, if the path exists, we propagate the user typed casing of the path and reuse it. This causes problems with some native tools like git where it expects correct casing of filesystem paths. The change is to step through the path and retrieve the actual casing of the items in the path and return that during the path normalization method.

PR Context

Fix #5678

PR Checklist

• PR has a meaningful title
  • Use the present tense and imperative mood when describing your changes
• Summarized changes
• Change is not breaking
• Make sure all .h, .cpp, .cs, .ps1 and .psm1 files have the correct copyright header
• This PR is ready to merge and is not Work in Progress.
  • If the PR is work in progress, please add the prefix WIP: or [ WIP ] to the beginning of the title (the WIP bot will keep its status check at Pending while the prefix is present) and remove the prefix when the PR is ready.
• User-facing changes
  • Not Applicable
  • OR
  • Documentation needed
    • Issue filed:
• Testing - New and feature
  • N/A or can only be tested interactively
  • OR
  • Make sure you've added a new test if existing tests do not effectively test the code changed

[SteveL-MSFT]

@PoshChan Please get failures

[PoshChan]

@SteveL-MSFT, test results were not published for PowerShell-CI-static-analysis at vstfs:///Build/Build/18523

[SteveL-MSFT]

@PoshChan Please get failures

[PoshChan]

@SteveL-MSFT, test results were not published for PowerShell-CI-static-analysis at vstfs:///Build/Build/18594

[SteveL-MSFT]

@PoshChan Please retry windows

[PoshChan]

@SteveL-MSFT, successfully started retry of PowerShell-CI-Windows

[SteveL-MSFT]

Hmmm, looks like the failures are due to handling of long path names which explains why it didn't fail on my machine. Might have to add some long path tests first.

[daxian-dbw]

@anmenaga Please merge by "Squash and Merge" in future unless we really want to preserve the PR history (should be rare).

[iSazonov]

@SteveL-MSFT @daxian-dbw
The change is performance expensive.
Version 6.2.3 vs latest local build:

PerfView:

We see a performance decreasing although overall performance of 7.0 builds is 2x better for file operations (like dir -Recurse)!

Also the trace shows that we call the method from some places several times. So the change slow down all file system operations without the need.

From original issue:

If I use cmd.exe instead, it gives the expected/desired results.

So I hope there is another way to fix the issue without perf degradation. I look cmd.exe and don't see that it does a path case normalization but works well. It seems we did not find a root of the issue and the fix is not in right place.

[daxian-dbw]

@iSazonov I see different results -- it's even slightly faster in 7.0.0-preview.5 comparing with 6.2.3.

[iSazonov]

@daxian-dbw I guess we use different cwd - my one is very long.
And obviously many folder enumeration (current fix) is slower then replacing slashes (before the fix).

[daxian-dbw]

@iSazonov I still cannot reproduce it using a long current working directory
Can you please provide a consistent repro using preview.5?

[iSazonov]

@daxian-dbw I tested on another system and I guess it is Kaspersky AV that slow down the CreateFileW P/Invoke. I still don't like these extra P/Invokes taking in account how cmd.exe and Windows PowerShell works.