Skip to content

New-Item -Target parameter mishandles paths that look like wildcard patterns when creating symbolic links / reparse points #14534

@mklement0

Description

@mklement0

Note: I'm writing this bug report from the perspective of the green-lit proposal to interpret -Target arguments as literal (verbatim) paths - see #13136. Perhaps these two issues can be tackled together.

By contrast, in Windows PowerShell you must escape paths that look like wildcard patterns, i.e. paths that contain [ and ].
Using this escaping as of PowerShell Core in 7.2.0-preview.2 doesn't work either, however, because the escaped path, while recognized as an existing item, is them mistakenly used verbatim as the link's target, resulting in a broken link.

Steps to reproduce

Push-Location ($tempDir = New-Item -Type Directory -Force "temp:/$PID")

try
{

  # Use a file name with '[' and ']' - without that, the test would succeed.
  $target = Join-Path $pwd.ProviderPath '[1] file.txt'

  # Create the file.
  $null = New-Item -Path $target -Value hi -Force

  # Try to create a symlink named 'lnk' in subdir. 'sub' (to be created on demand
  # with -Force) pointing to the newly created file.
  # Note:
  #  If ([WildcardPattern]::Escape($target)) is used to escape the path,
  #  the command *seemingly* succeeds, but the *escaped* path is mistakenly
  #  used *verbatim* as the target, quietly resulting in a *broken link*.
  { New-Item -ErrorAction Stop -Path sub/lnk -Type SymbolicLink -Force -Target $target } |
    Should -Not -Throw

} finally {

  Pop-Location
  Remove-Item -ErrorAction Ignore -LiteralPath $tempDir -Recurse -Force

}

Expected behavior

The test should succeed.

Actual behavior

The test fails, because (by design unescaped) $target isn't recognized as an existing item, even though the error message correctly lists the path:

...
Cannot find path '.../[1] file.txt' because it does not exist.
...

Environment data

PowerShell Core 7.2.0-preview.2

Metadata

Metadata

Assignees

No one assigned

    Labels

    Area-FileSystem-Providerspecific to the FileSystem providerIssue-Enhancementthe issue is more of a feature request than a bugResolution-No ActivityIssue has had no activity for 6 months or moreWG-Cmdlets-Managementcmdlets in the Microsoft.PowerShell.Management moduleWG-Engine-Providersbuilt-in PowerShell providers such as FileSystem, Certificates, Registry, etc.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions