Repository navigation
GCI of extended-length path "\\?\" returns incorrect items #14668
Description
Steps to reproduce
Get-ChildItem -LiteralPath '\\?\D:\'
Get-ChildItem -LiteralPath '\\?\UNC\server\share'
Expected behavior
Gets the items in the specified location.
Actual behavior
Gets the items in the root of the current drive (e.g. C:\). Same cmdlet in PSVersion 5.1 gets the items in the specified location.
Environment data
Name Value
---- -----
PSVersion 7.1.1
PSEdition Core
GitCommitId 7.1.1
OS Microsoft Windows 10.0.14393
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Reacted by Michael Klement
Activity
mklement0 commentedon Jan 26, 2021
Related: #10805
The short of it:
In PowerShell Core, long paths are supported by default, so the
\\?opt-in prefixes are never needed.However, they should still be supported, not least for the sake of cross-edition code - and currently, they're mostly not.
daxian-dbw commentedon Jan 27, 2021
Definitely a bug that needs to be fixed in my opinion. #14078 doesn't seem to include the specific problem this issue is about --
Get-ChildItem -LiteralPath '\\?\D:\'shows files/folders underC:\instead, so I think we should not close this issue as a dup.Steve Lee (@SteveL-MSFT) mentioned in #10805 (comment)
I'm not sure if that statement also applies to this issue. Happy to see other people's thoughts.
AlphaR3C0N commentedon Jun 9, 2021
Another use case for this old syntax is working with volumes in Windows that don't have drive letters (I know it's easy enough to assign letters but in some cases, you don't want to).
In the attached screenshot, both outputs should be the same (PS7.1.3 left, WPS5.1 right), instead PS7 returns the contents of C: for each volume (There are only 2 sets of results on the right cause the third volume was empty).
The path returned by
$volume.UniqueIdis the same in both versions (In format:\\?\Volume{0297bb38-1cf2-40db-abd1-8f7cb8539b8a}\) but after being passed throughGet-ChildItem, it always ends up beingC:in PS7.This was run on Windows 10 Enterprise 21H1.
MartinGC94 commentedon Apr 2, 2023
This seems to be working now so I guess this issue can be closed.
daxian-dbw commentedon Apr 3, 2023
I have verified this now works in PowerShell 7.4.0-preview.2, so closing the issue.