Skip to content

Registry provider: New-Item -Force shouldn't blindly recreate the leaf path component (registry key) #5444

Closed

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/bar

Expected 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)

Activity

  1. added
    WG-Engine-Providersbuilt-in PowerShell providers such as FileSystem, Certificates, Registry, etc.
    Issue-BugIssue has been identified as a bug in the product
    on Nov 14, 2017
  2. changed the title [-]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)[/+] on Nov 15, 2017
  3. Jaykul commented on Apr 26, 2018

    @Jaykul
    Contributor

    That's exactly what happens with leaf items in every provider (if you new-item -force -type file it blows away the file).

  4. mklement0 commented on Apr 26, 2018

    @mklement0
    ContributorAuthor

    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/bar doesn't blow away the content of an existing bar directory, neither should New-Item -Force HKCU:/foo/bar recreate key bar.

  5. microsoft-github-policy-service commented on Nov 16, 2023

    @microsoft-github-policy-service
    Contributor

    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.

  6. microsoft-github-policy-service commented on Nov 16, 2023

    @microsoft-github-policy-service
    Contributor

    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.

  7. microsoft-github-policy-service commented on Nov 16, 2023

    @microsoft-github-policy-service
    Contributor

    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.

  8. microsoft-github-policy-service commented on Nov 23, 2023

    @microsoft-github-policy-service
    Contributor

    This issue has been marked as "No Activity" as there has been no activity for 6 months. It has been closed for housekeeping purposes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Issue-BugIssue has been identified as a bug in the productResolution-No ActivityIssue has had no activity for 6 months or moreWG-Engine-Providersbuilt-in PowerShell providers such as FileSystem, Certificates, Registry, etc.

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions