-
Notifications
You must be signed in to change notification settings - Fork 8.1k
Closed
Labels
Area-FileSystem-Providerspecific to the FileSystem providerspecific to the FileSystem providerIssue-Enhancementthe issue is more of a feature request than a bugthe issue is more of a feature request than a bugResolution-No ActivityIssue has had no activity for 6 months or moreIssue has had no activity for 6 months or moreWG-Cmdlets-Managementcmdlets in the Microsoft.PowerShell.Management modulecmdlets in the Microsoft.PowerShell.Management moduleWG-Engine-Providersbuilt-in PowerShell providers such as FileSystem, Certificates, Registry, etc.built-in PowerShell providers such as FileSystem, Certificates, Registry, etc.
Description
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
rmachuca89, mtone and Hashbrown777
Metadata
Metadata
Assignees
Labels
Area-FileSystem-Providerspecific to the FileSystem providerspecific to the FileSystem providerIssue-Enhancementthe issue is more of a feature request than a bugthe issue is more of a feature request than a bugResolution-No ActivityIssue has had no activity for 6 months or moreIssue has had no activity for 6 months or moreWG-Cmdlets-Managementcmdlets in the Microsoft.PowerShell.Management modulecmdlets in the Microsoft.PowerShell.Management moduleWG-Engine-Providersbuilt-in PowerShell providers such as FileSystem, Certificates, Registry, etc.built-in PowerShell providers such as FileSystem, Certificates, Registry, etc.