Get-ChildItem -LiteralPath:'\\?\C:\Program Files' returns items from C:\ root

[ZonderP]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

Might be related to #15872, but I fear this bug is more fundamental.
When I call
Get-ChildItem -LiteralPath:'\\?\C:\Program Files' in Powershell Core 7.1.4
it returns all directories and files located on 'C:\' regardless of what the current work directory is.
As soon as the specified path does not exist, I get the expected error.
E.g.
Get-ChildItem -LiteralPath:'\\?\C:\Program Filessssss'
will display error: 'Get-ChildItem: Cannot find path '\\?\C:\Program Filessssss' because it does not exist.
Get-ChildItem -LiteralPath:'\\?\C:\Program Files' works as expected in Windows Powershell 5.1.
Originally I detected this error with this:
Get-ChildItem -LiteralPath:'\\?\UNC\autlet\QA\TestResults\Artist'
where '\\autlet\QA\TestResults\Artist' is an existing folder on shared drive '\\autlet\QA'.
also for this case Get-ChildItem returns the files and folders from root of drive C:\.
Also here, if I specify a not existing folder, I get the expected error.
E.g.
Get-ChildItem -LiteralPath:'\\?\UNC\autlet\QA\TestResults\Artistttt'
will display error 'Get-ChildItem: Cannot find path '\\?\UNC\autlet\QA\TestResults\Artistttt' because it does not exist.

I'm aware, that this syntax ('\\?\UNC\...' resp. '\\?C:\...') is not documented in the Powershell documentation for Get-ChildItem (https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-childitem?view=powershell-7.1 - neither for Windows Powershell 5.1 nor for Powershell Core 7.x), but this solution can often be found in the internet when searching for solutions to 'long path' problems.
If this syntax should not be supported, then it should give an error in each case.

Expected behavior

Get-ChildItem -LiteralPath:'\\?\C:\Program Files'

Should return the files and folders under 'C:\Program Files\'.

Actual behavior

Get-ChildItem -LiteralPath:'\\?\C:\Program Files'

Returns the files and folders under 'C:\'.

Error details

No response

Environment data

Name                           Value
----                           -----
PSVersion                      7.1.4
PSEdition                      Core
GitCommitId                    7.1.4
OS                             Microsoft Windows 10.0.19043
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visuals

#15872

[ZonderP]

Note that I would consider this bug (if it not only occurs for me for some reason) very serious.
Imagine something like
Get-ChildItem -LiteralPath:'\\?\UNC\autlet\QA\TestResults\Artist' -Force -File -Depth:5 | Remove-Item -Force
executed in an elevated session...
In my case it would more or less wipe out my system drive.

[lukeb1961]

I see the same failure with 7.2.0-preview.9
works fine on 5.1.19041.1237

[Hutoa]

Same here but I'm on 7.1.0 (Core)

I also need to work around 260 limit across '000s of files with varying path length and filename lengths. If unicode path support worked correctly it would be massive result for my project. No doubt I'll hit this elsewhere, I'll keep looking for an alternative for now.

There are features of 7.x I need so reverting to 5.1.x (mentioned above) is not an option.

[Binomimus]

Still an serious issue - and I almost went to delete things under C:\ ....

$PSVersionTable
Name                           Value
----                           -----
PSVersion                      7.2.1
PSEdition                      Core
GitCommitId                    7.2.1
OS                             Microsoft Windows 10.0.19044
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[Binomimus]

Still an issue in 7.2.2

Name                           Value
----                           -----
PSVersion                      7.2.2
PSEdition                      Core
GitCommitId                    7.2.2
OS                             Microsoft Windows 10.0.19044
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

[Johnlamsl]

Problem Also seen at
Powershell 7.2.2 at Windows 10 21H2 - Build 19044.1645

I am noticing a worse behaver

As you can see from My screen Shot

it doesn't only return to the Root

but it returns to your PowerShell operation root

For example
if you are working on the F: drive PowerShell

even if you enter

`\\?\C:\{What ever path it is}`

it will still Return to your F: Driver Root

and here is the .Net Version installed

PS C:\> dotnet --info
  It was not possible to find any installed .NET Core SDKs
  Did you mean to run .NET Core SDK commands? Install a .NET Core SDK from:
      https://aka.ms/dotnet-download

Host (useful for support):
  Version: 3.1.24
  Commit:  3b38386083

.NET Core SDKs installed:
  No SDKs were found.

.NET Core runtimes installed:
  Microsoft.AspNetCore.App 3.1.24 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
  Microsoft.NETCore.App 3.1.24 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 3.1.24 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET Core runtimes or SDKs:
  https://aka.ms/dotnet-download

@ZonderP

The "\?" prefix
it is documented here if you or anyone else need more refrence
https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file?redirectedfrom=MSDN#maximum-path-length-limitation

'Win32 File Namespaces
The Win32 namespace prefixing and conventions are summarized in this section and the following section, with descriptions of how they are used. Note that these examples are intended for use with the Windows API functions and do not all necessarily work with Windows shell applications such as Windows Explorer. For this reason there is a wider range of possible paths than is usually available from Windows shell applications, and Windows applications that take advantage of this can be developed using these namespace conventions.

For file I/O, the "\\?\" prefix to a path string tells the Windows APIs to disable all string parsing and to send the string that follows it straight to the file system. For example, if the file system supports large paths and file names, you can exceed the MAX_PATH limits that are otherwise enforced by the Windows APIs. For more information about the normal maximum path limitation, see the previous section [Maximum Path Length Limitation](https://docs.microsoft.com/en-us/windows/win32/fileio/naming-a-file?redirectedfrom=MSDN#maximum-path-length-limitation).

Because it turns off automatic expansion of the path string, the "\\?\" prefix also allows the use of ".." and "." in the path names, which can be useful if you are attempting to perform operations on a file with these otherwise reserved relative path specifiers as part of the fully qualified path.

Many but not all file I/O APIs support "\\?\"; you should look at the reference topic for each API to be sure.

Note that Unicode APIs should be used to make sure the "\\?\" prefix allows you to exceed the MAX_PATH'

[Binomimus]

Still an issue in 7.2.5

[ZonderP]

Doesn't seem to be important enough to be taken care of...
Still not fixed in 7.2.6 and in 7.2.0 preview.
I'm wondering... - since I still think that this bug is quite a severe issue.

[Johnlamsl]

looks normal to me at 7.3.9

[ZonderP]

Yes, it seems to now work in Powershell 7.3.9 as expected.
Can't remember, if it also didn't work in Windows Powershell 5.1, but it looks like that it works for Windows Powershell 5.1.14409.1018 under Windows 7! ;-) and 5.1.22621.2428 under Windows 11.
Doesn't work in Powershell Core 7.2.16, which is the last one which can be installed on Windows 7 - but well, I expect this to stay this way, since Windows 7 is long time not supported anymore.