Repository navigation
Bug: can not handle "/" correctly when reading registry item #5536
Description
Steps to reproduce
# ** careful "\" and "/" **
# initialization
New-Item 'registry::HKEY_CURRENT_USER/test'
New-ItemProperty 'registry::HKEY_CURRENT_USER\test' -Name test1 -Value test1
# read item.
Get-Item 'registry::HKEY_CURRENT_USER/test'
Set-ItemProperty 'registry::HKEY_CURRENT_USER/test' -Name test2 -Value abcde
# read and create item
Copy-Item 'registry::HKEY_CURRENT_USER/test' 'registry::HKEY_CURRENT_USER/test/t1'
Copy-Item 'registry::HKEY_CURRENT_USER\test' 'registry::HKEY_CURRENT_USER/test/t1'
# clear
Remove-Item 'registry::HKEY_CURRENT_USER\test' -Recurse -ForceExpected behavior
no errors
Actual behavior
Get-Item : Cannot find path 'HKEY_CURRENT_USER/test' because it does not exist.
At line:1 char:1
+ Get-Item 'registry::HKEY_CURRENT_USER/test'
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (HKEY_CURRENT_USER/test:String) [Get-Item], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.GetItemCommand
Set-ItemProperty : Cannot find path 'HKEY_CURRENT_USER/test' because it does not exist.
At line:1 char:1
+ Set-ItemProperty 'registry::HKEY_CURRENT_USER/test' -Name test2 -Valu ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (HKEY_CURRENT_USER/test:String) [Set-ItemProperty], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.SetItemPropertyCommand
Copy-Item : Cannot find path 'HKEY_CURRENT_USER/test' because it does not exist.
At line:1 char:1
+ Copy-Item 'registry::HKEY_CURRENT_USER/test' 'registry::HKEY_CURRENT_ ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (HKEY_CURRENT_USER/test:String) [Copy-Item], ItemNotFoundException
+ FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.CopyItemCommand
Environment data
> $PSVersionTable
Name Value
---- -----
PSVersion 6.0.0-rc
PSEdition Core
GitCommitId v6.0.0-rc
OS Microsoft Windows 10.0.16299
Platform Win32NT
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...}
PSRemotingProtocolVersion 2.3
SerializationVersion 1.1.0.1
WSManStackVersion 3.0Summary
after trying, I found the law.
- can handle "/" correctly when creating item.
- can not handle "/" correctly when reading item.
related cmdlets
New-Item
New-ItemPropert
Get-ChildItem
Get-Item
Get-ItemProperty
Get-ItemPropertyValue
Set-Item
Set-ItemProperty
Clear-Item
Clear-ItemProperty
Remove-Item
Remove-ItemProperty
Rename-Itemre
Rename-ItemProperty
Copy-Item
Copy-ItemProperty
Move-Item
Move-ItemProperty
Activity
ZSkycat commentedon Nov 24, 2017
This bug also exists in Windows PowerShell (no core)
iSazonov commentedon Nov 24, 2017
'/' is allowed in registry key names. Can you to try escape '/'?
ZSkycat commentedon Nov 24, 2017
Ilya (@iSazonov)
I am using
\to avoid this bug.but I like automatic processing slash in powershell. (like file path)
mklement0 commentedon Nov 25, 2017
To be clear: The real bug is that
/is supported at all as a path separator by the registry provider (even though the desire to use/and\interchangeably, as with the file-system provider, is understandable).As Ilya (@iSazonov) points out,
/is a valid character in a registry key (or value) name; therefore, it cannot function as the path separator, which in the registry provider's case should only be\.(Unfortunately, the objects returned by
Get-PSProviderhave no property that indicates a provider's path separator(s).)Using one of your examples:
That
New-Item 'registry::HKEY_CURRENT_USER/test'succeeds and functions the same asNew-Item 'registry::HKEY_CURRENT_USER\test'is a manifestation of the bug.ZSkycat commentedon Nov 25, 2017
Michael Klement (@mklement0) I understand.
item name allow use '/' is too bad
😂😂😂
iSazonov commentedon Nov 25, 2017
That's why I'm more inclined to think that we need to optimize providers and use types instead of strings.
mklement0 commentedon Nov 25, 2017
Ilya (@iSazonov): What do you mean by using types instead of strings?
iSazonov commentedon Nov 25, 2017
Providers work with strings and do parsing its on every operation. This results in poor performance and problems like this.
rjmholt commentedon Mar 7, 2018
Tracing this, it looks like there has already been some consideration of this in the
NavigationProviderbase class here.The comment seems to indicate that unless both back and forwards slashes are used, we want to treat forward slashes as back slashes. That seems a bit strange to me, but looking for input.
16 remaining items
iSazonov commentedon Oct 14, 2019
Steve Lee (@SteveL-MSFT) Taking in account #10215 (PowerShell crash) please weigh the issue.
SteveL-MSFT commentedon Oct 14, 2019
Ilya (@iSazonov) since the recursion issue repros with 5.1, this is not a regression. It's also an unlikely user scenario and I haven't seen many reports of this. I would like to have this fixed, but I don't think it changes the priority.
vanillaSprinkles commentedon May 16, 2021
It absolutely is inappropriately normalizing the path and causes a few other problems, I realize now I should've posted to this thread a fix, but I believe
result = path.Replace(StringLiterals.AlternatePathSeparator, StringLiterals.DefaultPathSeparator);is the culprit and would likely remove quite a few issues (issue above references the correct line number).The registry allows slashes
/in key names, plain and simple. Take a look at theEdgeExtensionswithin and look at those beautiful key-names:HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\Windows\CurrentVersion\AppContainer\Storage\microsoft.microsoftedge_8wekyb3d8bbwe\EdgeExtensions\Configuration\EdgeExtensions\ConfigurationStore\ExtensionsDeadooshka commentedon Jul 13, 2023
got almost a same bug. Create some registry key 'Some_key' and create a subkey named '/' (slash only). Run
Get-ChildItem -LiteralPath 'Registry::Some_key' -Recurse. You will see eternal repeating.microsoft-github-policy-service commentedon Jan 10, 2024
This issue has not had any activity in 6 months, if there is no further activity in 7 days, the issue will be closed automatically.
Activity in this case refers only to comments on the issue. If the issue is closed and you are the author, you can re-open the issue using the button below. Please add more information to be considered during retriage. If you are not the author but the issue is impacting you after it has been closed, please submit a new issue with updated details and a link to this issue and the original.