Add --fix-bad flag to choco cleanup to recover .registry.bad files

[necrose99]

Checklist

• I have verified this is the correct repository for opening this issue.
• I have verified no other issues exist related to my request.

Is Your Feature Request Related To A Problem? Please describe.

Yes. When Chocolatey metadata is interrupted (often by GUI wrappers like WingetUI/UniGet or system crashes), it renames .registry to .registry.bad. The current "fix" requires the user to manually navigate deep directory trees and rename files via PowerShell or CMD, as Windows Explorer often blocks these actions.

Describe the solution you'd like
I would like a new flag for the cleanup command: choco cleanup --fix-bad.
This flag should:

Recursively search the Chocolatey installation directory for .registry.bad files.

Automatically restore them to .registry status (overwriting empty/corrupt files if necessary).

Remove 0-byte (null) registry files that prevent successful package tracking.

Proof of Concept (PowerShell)
Here is a functional script that handles this logic today:

# Proposed logic for --fix-bad implementation
$basePath = "$($env:ChocolateyInstall)" # Dynamically target the install root

Write-Host "Searching for corrupt registry files in $basePath..." -ForegroundColor Cyan

# 1. Recover .registry.bad files
$badFiles = Get-ChildItem -Path $basePath -Filter ".registry.bad" -Recurse -ErrorAction SilentlyContinue
foreach ($file in $badFiles) {
    $targetPath = Join-Path -Path $file.DirectoryName -ChildPath ".registry"
    Move-Item -Path $file.FullName -Destination $targetPath -Force -Confirm:$false
    Write-Host "RECOVERED: $($file.FullName) -> .registry" -ForegroundColor Green
}

# 2. Purge 0-byte 'ghost' registry files
$emptyFiles = Get-ChildItem -Path $basePath -Filter ".registry" -Recurse | Where-Object { $_.Length -eq 0 }
foreach ($empty in $emptyFiles) {
    Remove-Item $empty.FullName -Force
    Write-Host "REMOVED: Empty registry file at $($empty.FullName)" -ForegroundColor Yellow
}

Describe The Solution. Why is it needed?

Describe alternatives you've considered
The current alternative is a manual "search and replace" mission in C:\ProgramData\chocolatey, which is error-prone for average users.

User Story

Describe alternatives you've considered
Manually deleting the package folder and reinstalling, which loses local tracking and configuration history.

or janky scripts to purge bad files and run choco upgrade --force -y

Additional Context

its more a quality of life / niice to have

Acceptance Criteria

No response

Related Issues

No response

[github-actions]

To vote for this issue, please add a 👍 emoji to the issue description. Votes in comments are not recorded.

[necrose99]

# Proposed logic for 'choco cleanup --fix-bad'
$basePath = "$env:ChocolateyInstall"
<#
    .SYNOPSIS
        Fixes .registry.bad , wingetui aka uniget choco gui aka chcolateey helpers : sometimes goes fast n slightly breaks stuff 
		C:\ProgramData\chocolatey\ or also in .chocolatey appended to chco root folder... 
		bit of quick gargbage cleaning  i have a simular script thus cleaning out errors from ...."bad files "	speeding things up 	 as having dozens of these slows up chco-upgrades as recursive errors etc.  display , cleaning them out gives back some speed 
		as it can get irritating to clean them out by hand  
    #>
Write-Host "Reconciling Chocolatey metadata in $basePath..." -ForegroundColor Cyan

# 1. Process .registry.bad files with conflict resolution
$badFiles = Get-ChildItem -Path $basePath -Filter ".registry.bad" -Recurse -ErrorAction SilentlyContinue

foreach ($file in $badFiles) {
    $targetPath = Join-Path -Path $file.DirectoryName -ChildPath ".registry"
    
    if (Test-Path $targetPath) {
        $existingSize = (Get-Item $targetPath).Length
        if ($existingSize -gt 0) {
            # .registry is healthy; .bad is redundant
            Remove-Item $file.FullName -Force
            Write-Host "CLEANED: Removed redundant $($file.Name)." -ForegroundColor Yellow
        } else {
            # .registry is empty; overwrite with .bad
            Move-Item $file.FullName -Destination $targetPath -Force
            Write-Host "RECOVERED: Replaced empty .registry with $($file.Name)." -ForegroundColor Green
        }
    } else {
        # Standard restoration
        Move-Item $file.FullName -Destination $targetPath
        Write-Host "RESTORED: $($file.Name) -> .registry" -ForegroundColor Green
    }
}

# 2. Cleanup remaining 0-byte 'ghost' files
Get-ChildItem -Path $basePath -Filter ".registry" -Recurse | 
    Where-Object { $_.Length -eq 0 } | 
    Remove-Item -Force

[gep13]

@necrose99 thank you for raising this issue. I agree, that this is likely something that should be handled by Chocolatey CLI.

A couple of follow up questions...

• There currently is no choco cleanup command, so you are suggesting that a new command is created, correct?
• The provided sample script, while helpful to illustrate what you think is required, would ultimately have to be written in C#. That doesn't change what you are suggesting here though, correct?
• It would be good to understand exactly what is causing the files to be changed to .bad in the first place. You mentioned that this could be down to WingetUI/UniGet or system crashes, do you have any reproducible steps to cause a .bad file to be created in the first place?
• Simply removing the .bad suffix might not actually be enough to fix the problem, since there might actually still be something wrong with the file. If we take this on, we should likely verify that the file can be serialized/deserialized correctly, before renaming it.
• The information in the registry files is only available at the point of installation of a package, and therefore it can't be easily recovered. Perhaps what we need is to also store the collected information in a different location, so that it can be recovered, if/when a .bad version of the file is created. This would seem to be the best way forward, i.e. rather than create a .bad file in the first place, recover for the other location. Thoughts?

I will continue to think about this situation, and will come back to this if I have anything else to add to this.

For now, I will mark the issue as Waiting on User until I hear from you about the above questions. Thanks!