Repository navigation
new-item cannot create hardlinks with [] in the name on win10 #14960
Description
When attempting to create a hardlink with special characters in powershell 7.1, the command fails with the message
New-Item: Cannot find path 'D:\debugging\[name] with special chars.txt' because it does not exist.
for items with the special characters []
I have attempted to create a hardlink with the mklink /H command on the commandpromt, Which is able to accept targets with special characters.
Since the commandprompt is able to do this, I would expect to be able to do the same with powershell
Steps to reproduce
# Validating being able to create normal hardlinks
New-Item -ItemType HardLink -Target (Resolve-Path .\test.txt) -Path "./test-hard.txt"
New-Item -ItemType HardLink -Target (Resolve-Path '.\test name.txt') -Path "./test-hard spaced.txt"
# attempting to create a hardlink with `[]` in the name
New-Item -ItemType HardLink -Target (Resolve-Path '.\`[name`] with special chars.txt') -Path "./test-hard spaced 2.txt"Expected behavior
Powershell creates a hardlink named test-hard spaced 2.txt in the current directory.
Directory: D:\debugging
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a--- 7-3-2021 15:21 0 test-hard spaced 2.txt
Actual behavior
The Cmdlet fails with the following message
New-Item: Cannot find path 'D:\debugging\[name] with special chars.txt' because it does not exist.
I have validated that the target file actually exists in the file explorer, and the command prompt is able to handle this case just fine with the mklink tool. Provided you escape the name correctly.
D:\debugging>mklink /H "test-hard spaced 2.txt" "[name] with special chars.txt"
Hardlink created for test-hard spaced 2.txt <<===>> [name] with special chars.txt
Environment data
PSVersion 7.1.2
PSEdition Core
GitCommitId 7.1.2
OS Microsoft Windows 10.0.19042
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0
Activity
p0W3RH311 commentedon Mar 7, 2021
try to execute Resolve-Path with -LiteralPath
LDSpits commentedon Mar 7, 2021
This still gives me a failure
mklement0 commentedon Mar 7, 2021
Please see #14534
237dmitry commentedon Mar 7, 2021
It works for me:
mklement0 commentedon Mar 7, 2021
237dmitry, this is about the
-Targetparameter, not the-Nameparameter.237dmitry commentedon Mar 8, 2021
I'm sorry, I'm always inattentive. mklink is of course easier.
Double `` as escapes
mklement0 commentedon Mar 8, 2021
237dmitry, while it's good to know about workarounds, this is ultimately about fixing PowerShell's behavior, as discussed in #14534.
Specifically:
mklinkis not only Windows-specific, it is a command internal tocmd.exe.While doubly escaping the
[and]characters with two`characters happens to work, that in itself is a bug - see Backtick escaping inconsistent #7999mklement0 commentedon Mar 8, 2021
Another way of putting it:
If we accepted the - questionable - premise that the
-Value/-Targetargument should be interpreted as a wildcard pattern:[WildcardPattern]::Escape('C:\Path\To\file [123].txt')- i.e.'C:\Path\To\file `[123`].txt'- should work: one verbatim`to escape each metacharacter.We shouldn't accept this premise, however, because that argument should be interpreted as a literal (verbatim) path.
abaumgaertner commentedon Apr 5, 2021
similar issue #6232
CCRcmcpe commentedon Nov 15, 2022
How this is still an open issue in 2022?
New-Item -ItemType SymbolicLinkwith-Targetcontains[]still does not work.daxian-dbw commentedon Jun 12, 2023
The Engine WG reviewed this issue and believe this is a duplicate of #14534. Will close this issue as a duplicate.