powershellpowershell-5.0uncget-childitem

Powershell get-childitem works different with long-path prefix (\\?\)


I have different results in these two cases:

If the long path is less than 260 characters long, I have diferent results.

For getting same results, I should do different in case 1:

Get-ChildItem -Path "\\?\UNC\very\long\path\*"

Why this difference? I use \\?\UNC prefix because the fullpath is variable and I do not know it.

Perhaps I should use \* wildcard in both cases?


Solution

  • You're seeing a bug in Windows PowerShell that surfaces when you pass literal paths (non-wildcard) paths using a long-path prefix (\\?\ for local paths, \\?\Unc\ for UNC paths) to the (possibly positionally implied) -Path parameter. See the bottom section for details.

    To work around it, use the -LiteralPath parameter instead, which is the right thing to do for non-wildcard paths anyway:

    Get-ChildItem -LiteralPath \\?\UNC\server1\share1\very\long\path
    

    Note:


    Windows PowerShell bug details:

    The bug surfaces when you pass a non-wildcard root path that has a long-path prefix to -Path, which applies to both using the local and the UNC forms of the prefix, though the symptoms differ:

    # UNC root path: 
    # NO OUTPUT
    Get-ChildItem -Path \\?\UNC\server1\share1
    
    # LOCAL root path:
    # -> SPURIOUS ERROR "Cannot retrieve Cannot retrieve the dynamic parameters for the cmdlet. ..."
    Get-ChildItem -Path \\?\C:\
    

    Appending at least one additional path component makes the problem go away; e.g.:

    # Both OK, due to addition of another path component.
    Get-ChildItem -Path \\?\UNC\server1\share1\subfolder
    Get-ChildItem -Path \\?\C:\Windows
    

    Curiously, however, the local form doesn't support wildcards on the level of the drive root:

    # !! NO OUTPUT
    Get-ChildItem -Path \\?\C:\*
    
    # By contrast, wildcards DO work with the UNC prefix at the 
    # top-level of the share
    Get-ChildItem -Path \\?\UNC\server1\share1\*
    

    As an aside: