Repository navigation
On Unix, PowerShell will not find files with backslashes in their names #3666
Description
This is similar to #3414, but involves only the backslash portion.
The basis of the problem is premature normalization of paths. Path normalization happens quite early (and very frequently and in a great number of places in the PowerShell code) while processing a command. Usually this happens before the path reaches its provider, and often that normalization is a brute-force change one slash to another mechanism. Thus a path such as 1\2 on Unix is "normalized" to 1/2, ensuring that the path will never be found.
Using -LiteralPath does not prevent the path normalization, so that is not a workaround.
Steps to reproduce
From bash:
$ touch 'a\b'then from PowerShell:
PS> Remove-Item a\bor
PS> Move-Item a\b a-bExpected behavior
The file a\b is deleted
Actual behavior
Remove-Item : Cannot find path 'a/b' because it does not exist.
At line:1 char:1
+ Remove-Item a\b
+ ~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (a/b:String)
[Remove-Item], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.RemoveItemCommand
Environment data
> $PSVersionTable
Name Value
---- -----
BuildVersion 3.0.0.0
CLRVersion
GitCommitId v6.0.0-alpha.18-38-g08e855556cff42274a5903799b826e78d0c...
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSEdition Core
PSRemotingProtocolVersion 2.3
PSVersion 6.0.0-alpha
SerializationVersion 1.1.0.1
WSManStackVersion 3.0 Reacted by Michael Klement
Activity
iSazonov commentedon May 1, 2017
On Windows the same:
jeffbi commentedon May 1, 2017
Ilya (@iSazonov) I think this is a separate issue. It may turn out to be related to path normalization, but I still think it should have it's own issue.
This one is about attempting to rename, remove or move an existing file. The error message in this case is
Cannot find path '1\2' because it does not exist.rather thanCould not find a part of the path 'C:\temp\1\2'.I think you'd be unlikely to run into this in Windows, at least on its native file systems, since both forward and backslashes are disallowed. In Unix forward slashes are allowed, and it's simple create, from bash or other programs, a file with forward slashed in the name.
iSazonov commentedon May 2, 2017
It seems this should apply to the type of the file system and not to a platform.
iSazonov commentedon May 2, 2017
Interesting, Is
[System.IO.Path]::GetInvalidPathChars()and[System.IO.Path]::GetInvalidFileNameChars()based on a platform or a file system type?jeffbi commentedon May 2, 2017
Ilya (@iSazonov) I would love to see this based on file system type rather than platform, along with a number of other areas. One problem is that I haven't found a way to definitively identify an NTFS file system under Linux.
Regarding
[System.IO.Path]::GetInvalidPathChars()and[System.IO.Path]::GetInvalidFileNameChars(), there appear to be separate implementations for each platform in coreclr.It seems that the notion of illegal characters is largely platform-based rather than file system based. As an experiment, I created a file named
a>b<c:?|on an NTFS volume on my Linux box with thetouchcommand. There are five characters in there that Windows considers to be illegal, but the NTFS file system accepts them and Windows displays the file properly in Windows Explorer. I can't do anything with it on Windows, such open or delete it, but it is recognized.iSazonov commentedon May 2, 2017
This is specificity of higher-level API (Win2k).
If so we must always follow the same rule and be platform based.We will not be able to be more flexible 😕
27 remaining items
Serentty commentedon May 17, 2020
I ran into this today when I accidentally created two directories with
mkdir(the Linux version) instead of one with a space in its name, since I was trying to use the backslash to escape the space as I'm used to (I'm aware that PowerShell uses a different escape character). Afterwards, I was unable to delete the one whose name ended in a backslash.NicolaiLolansen commentedon Oct 23, 2020
When trying to run files with
bashin powershell, the tab-completion resorts to doingbash .\script.shwhich then won't find the file. Runningbash script.shorbash ./script.shworks fine, but the tab-completion uses.\which does not work.Kuinox commentedon Mar 7, 2024
Hey Steve Lee (@SteveL-MSFT), your bot auto-closed this issue, the bug still exists.
somescout commentedon Jun 23, 2026
The issue still exists and is still annoying