René's URL Explorer Experiment

{"@context":"https://schema.org","@type":"DiscussionForumPosting","headline":"Windows (NTFS): Inconsistent support for the long-path prefix (\\\\?\\) in filesystem paths","articleBody":"Note: This is a generalization of #4439. @SteveL-MSFT, if you agree, please close the latter.\r\n\r\nPrefixing full, normalized, native filesystem paths with `\\\\?\\` allows targeting filesystem items whose path is longer than the legacy limit of 259 characters.\r\n\r\n**Update**: \r\n * Prefix `\\\\?\\` isn't _needed_ in PS Core (in .NET Core altogether), so long paths just work as-is, even if not enabled system-wide. \r\n * However, old code may still use it, and even new code may have to, when creating cross-edition scripts.\r\n * Additionally, and separately, `\\\\?\\`  is useful for targeting files or directories with _irregular names_, such as ones with _trailing spaces_, so you can remove them with `Remove-Item`, for instance.\r\n\r\nAs an aside: In Windows 10 you can now opt in system-wide to support long paths, but individual applications must _also_ opt in (PowerShell indirectly does) - see https://blogs.msdn.microsoft.com/jeremykuhne/2016/07/30/net-4-6-2-and-long-paths-on-windows-10/\r\n\r\nAs of PowerShell Core 7.3.0-preview.2, the **inconsistent support for `\\\\?\\` is as follows**:\r\n\r\n* With the **`-Path`** parameter, **`\\\\?\\` isn't supported _at all_** , so wildcard expressions cannot be used. \r\n  * `Get-Item` and `Get-ChildItem` output nothing, and `Remove-Item` is a quiet no-op (silent failure) too. \r\n\r\n* With the **`-LiteralPath`** parameter in combination with `\\\\?\\`:\r\n  *  Only _file paths_ can be targeted.\r\n  * _Directory_ paths exhibit the following behavior:\r\n     * `Get-Item` and `Remove-Item` complain about not finding the path. \r\n        * Adding `-Force` makes `Get-Item` output a broken `DirectoryInfo` instance.  \r\n        * Using `Remove-Item` without `-Recurse` on a nonempty directory presents the usual confirmation prompt (implying the ability to recognize the path as existent), but then fails on confirmation.\r\n     * `Get-ChildItem` reports the _root_ directory's content instead(!)\r\n\r\nAdditionally, `\\\\?\\` paths do _not_ work in the following cases:\r\n\r\n*  With  `\u003e` / `\u003e\u003e`, which implicitly behave like `Out-File -Path` - see #4726\r\n\r\n* \u003cdel\u003eIn the same vein, _invocation of an executable_ - whether with or without `\u0026` - is broken (possibly related to #4726 as well).\u003c/del\u003e (no longer a problem as of PowerShell Core 7.3.0-preview.2)\r\n\r\n* \u003cdel\u003e`Start-Process`\u003c/del\u003e (no longer a problem as of PowerShell Core 7.3.0-preview.2)\r\n\r\n* `Set-Location` (not even with `-LiteralPath`)\r\n\r\nNote: \r\n\r\n* Some of these problems are regressions from Windows PowerShell, where only the invocation / `Start-Process` tests fail and `\u003e` only with a _new_ file.\r\n\r\n* I haven't looked into whether invoking an _executable_ with an overly long path is supported in principle by the underlying APIs.\r\n\r\n# Steps to reproduce\r\n\r\nRun the following from a Pester test script (`*.Tests.ps1`) on Windows:\r\n\r\n```powershell\r\nDescribe \"Support for long paths, via \\\\?\\\" {\r\n  BeforeAll {\r\n    Push-Location (Convert-Path TestDrive:\\)\r\n    $dirPath = $PWD.ProviderPath\r\n    $PrefixedDir = \"\\\\?\\$dirPath\"\r\n    $fileName = ('a' * 248 + '.cmd')\r\n    $fileNameAlt = ('b' * 248)\r\n    $PrefixedFullName = \"$PrefixedDir\\$fileName\"\r\n    $PrefixedFullNameAlt = \"$PrefixedDir\\$fileNameAlt\"\r\n    # Create the file with the overly long path using .NET,\r\n    # to avoid issues with New-Item\r\n    [IO.File]::WriteAllText($PrefixedFullName, '')\r\n  }\r\n  It \"Get-ChildItem -LiteralPath\" {\r\n    Get-ChildItem -LiteralPath $PrefixedFullName | % FullName | Should -Be $PrefixedFullName\r\n  }\r\n  It \"Get-ChildItem -Path\" {\r\n    Get-ChildItem -Path $PrefixedFullName | % FullName | Should -Be $PrefixedFullName\r\n  }\r\n  It \"Remove-Item -LiteralPath\" {\r\n    { Remove-Item -LiteralPath $PrefixedFullName } | Should -Not -Throw\r\n    # Recreate the file.\r\n    [IO.File]::WriteAllText($PrefixedFullName, '')\r\n  }\r\n  It \"Remove-Item -Path\" {\r\n    { Remove-Item -Path $PrefixedFullName } | Should -Not -Throw\r\n    # Recreate the file, if necessary\r\n    [IO.File]::WriteAllText($PrefixedFullName, '')\r\n  }\r\n  It \"\u003e with new file\" {\r\n    { '' \u003e  $PrefixedFullNameAlt } | Should -Not -Throw\r\n  }\r\n  It \"\u003e / \u003e\u003e with existing file.\" {\r\n    { '@echo Hi.' \u003e  $PrefixedFullName } | Should -Not -Throw\r\n    { 'REM ' \u003e\u003e $PrefixedFullName } | Should -Not -Throw\r\n  }\r\n  It \"Invocation / \u0026\" {\r\n    \u0026 $PrefixedFullName | Should -Be 'Hi.'\r\n  }\r\n  It \"Start-Process\" {\r\n    Start-Process -FilePath $PrefixedFullName\r\n  }\r\n  It \"New-Item\" {\r\n    { New-Item -Force -Type File $PrefixedFullName } | Should -Not -Throw\r\n  }\r\n  It \"Set-Location -LiteralPath\" {\r\n    { Set-Location -EA Stop -LiteralPath $PrefixedDir } | Should -Not -Throw\r\n  }\r\n  It \"Set-Location -Path\" {\r\n    { Set-Location -EA Stop -Path $PrefixedDir } | Should -Not -Throw\r\n  }\r\n  AfterAll {\r\n    # Use .NET to remove the overly long path, so that Pester itself doesn't \r\n    # fail on trying to remove the dir. underlying TestDrive:\r\n    [IO.File]::Delete($PrefixedFullName)\r\n    [IO.File]::Delete($PrefixedFullNameAlt)\r\n    Pop-Location\r\n  }\r\n}\r\n```\r\n\r\n# Expected behavior\r\n\r\nAll tests should pass.\r\n\r\n# Actual behavior\r\n\r\nAll tests but the first one fail, with various error messages.\r\n\r\n# Environment data\r\n\r\n```none\r\nPowerShell Core 7.0.0-preview.4\r\n```\r\n","author":{"url":"https://github.com/mklement0","@type":"Person","name":"mklement0"},"datePublished":"2019-10-16T16:51:10.000Z","interactionStatistic":{"@type":"InteractionCounter","interactionType":"https://schema.org/CommentAction","userInteractionCount":38},"url":"https://github.com/10805/PowerShell/issues/10805"}