Repository navigation
Registry provider: New-Item -Force shouldn't blindly recreate the leaf path component (registry key) #5444
Copy link
Copy link
Closed
Labels
Issue-BugIssue has been identified as a bug in the productIssue has been identified as a bug in the productResolution-No ActivityIssue has had no activity for 6 months or moreIssue has had no activity for 6 months or moreWG-Engine-Providersbuilt-in PowerShell providers such as FileSystem, Certificates, Registry, etc.built-in PowerShell providers such as FileSystem, Certificates, Registry, etc.
Description
New-Item -Force, at least with the filesystem provider, commendably employs desired-state logic with directories (update: see comment below for why registry keys should be considered the analog of directories, not files):
If the specified path doesn't exist yet, it is created; if it already does, no action is taken (and no error is reported).
By contrast, the registry provider currently blindly recreates the leaf component of the path, which can result in data loss.
Steps to reproduce
# Create HKCU:/foo/bar with value 'baz1'; -Force ensures that ancestral component `foo` is implicitly created.
New-Item -Force HKCU:/foo/bar | Set-ItemProperty -Name baz1 -Value 1
# Now - seemingly - add another value, 'baz2'
New-Item -Force HKCU:/foo/bar | Set-ItemProperty -Name baz2 -Value 2
# List the resulting values.
Get-Item HKCU:/foo/barExpected behavior
Hive: HKEY_CURRENT_USER\foo
Name Property
---- --------
bar baz1 : 1
baz2 : 2
Actual behavior
Hive: HKEY_CURRENT_USER\foo
Name Property
---- --------
bar baz2 : 2
Only baz2 is present, because New-Item -Force HKCU:/foo/bar recreated the bar key, wiping out baz1 in the process.
Environment data
PowerShell Core v6.0.0-beta.9 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)
Windows PowerShell v5.1.15063.674 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
Issue-BugIssue has been identified as a bug in the productIssue has been identified as a bug in the productResolution-No ActivityIssue has had no activity for 6 months or moreIssue has had no activity for 6 months or moreWG-Engine-Providersbuilt-in PowerShell providers such as FileSystem, Certificates, Registry, etc.built-in PowerShell providers such as FileSystem, Certificates, Registry, etc.
Activity
[-]Registry provider: New-Item -Force shouldn't blindly recreate the leaf path component (key)[/-][+]Registry provider: New-Item -Force shouldn't blindly recreate the leaf path component (registry key)[/+]Jaykul commentedon Apr 26, 2018
That's exactly what happens with leaf items in every provider (if you
new-item -force -type fileit blows away the file).mklement0 commentedon Apr 26, 2018
Joel Bennett (@Jaykul):
That's true with files, yes, but the registry provider has no item sub-type that is the analog of a file - there's only one item type - a registry key - and it is always a container, and thus the equivalent of a directory.
Thus, my argument is: just as
New-Item -Type Directory -Force /foo/bardoesn't blow away the content of an existingbardirectory, neither shouldNew-Item -Force HKCU:/foo/barrecreate keybar.microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 16, 2023
This issue has not had any activity in 6 months, if this is a bug please try to reproduce on the latest version of PowerShell and reopen a new issue and reference this issue if this is still a blocker for you.
microsoft-github-policy-service commentedon Nov 23, 2023
This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.