Description

mccarrm

opened on Jan 26, 2021

Issue body actions

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

1. mccarrm

   added

   Needs-TriageThe issue is new and needs to be triaged by a work group.The issue is new and needs to be triaged by a work group.

   on Jan 26, 2021
2. mklement0 commented on Jan 26, 2021

   

   Michael Klement (mklement0)

   on Jan 26, 2021

   Contributor

   More actions

   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.
3. Ilya (iSazonov)

   added

   Issue-BugIssue has been identified as a bug in the productIssue has been identified as a bug in the product

   WG-Engine-Providersbuilt-in PowerShell providers such as FileSystem, Certificates, Registry, etc.built-in PowerShell providers such as FileSystem, Certificates, Registry, etc.

   on Jan 27, 2021
4. Dongbo Wang (daxian-dbw)

   removed

   Needs-TriageThe issue is new and needs to be triaged by a work group.The issue is new and needs to be triaged by a work group.

   on Jan 27, 2021
5. daxian-dbw commented on Jan 27, 2021

   

   Dongbo Wang (daxian-dbw)

   on Jan 27, 2021

   Member

   More actions

   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 under C:\ instead, so I think we should not close this issue as a dup.

   Steve Lee (@SteveL-MSFT) mentioned in #10805 (comment)

   I get that users may want to use the \?\ legacy syntax, but it's not clear to me how impactful that is to motivate spending the time to fix this.

   I'm not sure if that statement also applies to this issue. Happy to see other people's thoughts.

   Reacted by Michael Klement, Eugene Vilensky and AlphaR3C0N
6. AlphaR3C0N commented on Jun 9, 2021

   

   AlphaR3C0N

   on Jun 9, 2021

   More actions

   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.UniqueId is the same in both versions (In format: \\?\Volume{0297bb38-1cf2-40db-abd1-8f7cb8539b8a}\) but after being passed through Get-ChildItem, it always ends up being C: in PS7.

   This was run on Windows 10 Enterprise 21H1.

   
7. Ilya (iSazonov)

   added

   Area-FileSystem-Providerspecific to the FileSystem providerspecific to the FileSystem provider

   WG-Cmdlets-Management

   on Nov 30, 2021
8. MartinGC94 commented on Apr 2, 2023

   

   MartinGC94

   on Apr 2, 2023

   Contributor

   More actions

   This seems to be working now so I guess this issue can be closed.
9. daxian-dbw commented on Apr 3, 2023

   

   Dongbo Wang (daxian-dbw)

   on Apr 3, 2023

   Member

   More actions

   I have verified this now works in PowerShell 7.4.0-preview.2, so closing the issue.

   
10. Dongbo Wang (daxian-dbw)

    added

    Resolution-FixedThe issue is fixed.The issue is fixed.

    on Apr 3, 2023
12. ghost closed this as completedon Apr 5, 2023
13. Ryan Yates (kilasuit)

    added

    WG-Cmdletsgeneral cmdlet issuesgeneral cmdlet issues

    and removed

    WG-Cmdlets-Management

    on Jul 17, 2026

Issue actions