Use Powershell to delete ShellIconOverlayIdentifiers on Windows-CodePudding

I am currently very annoyed by Dropbox and Nextcloud, which both battle the ShellIconOverlayIdentifier list. A problem which many people seem to have, when you search the internet.

Now I want to combine my annoyance with my intent to learn powershell (7.2.0).

I started with the following script, which shall retrieve all keys. And later I want to use regex via -match to find the entries I want to delete. For now I work with both Remove-Item -WhatIf and Get-ItemProperty to test it.

Currently my problem is that I can create my list as intended. But when I feed the list into the remove command I get that the path cannot be found. What am I doing wrong?

Push-Location -Path Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers

$list = Get-ChildItem -Path .

$filteredList = $list -match "DropboxExt10"

$filteredList

# Remove-Item -WhatIf -Recurse $filteredList
Get-ItemProperty $filteredList

Pop-Location

The error is Cannot find path 'Microsoft.PowerShell.Core\Registry::HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\ShellIconOverlayIdentifiers\ DropboxExt10' because it does not exist. Apparantly it adds the path as relative path to the current location. Why doesn't it interpret as an absolute path? When I ommit the push-location part it trys to add the registry path to my current working directory in which the script lives. But this is wrong as well.

Thanks for your help in advance.

CodePudding user response：

Use one of the following:

$filteredList | Remove-Item -WhatIf -Recurse

# Alternatively:
Remove-Item -LiteralPath $filteredList.PSPath -WhatIf -Recurse

The above commands ensure that the registry items (keys) are bound by their full, provider-qualified paths to Remove-Item's -LiteralPath parameter, via their .PSPath property; in the case of registry paths, the path's provider prefix is Microsoft.PowerShell.Core\Registry:: (or, if identifying the originating module isn't also required, Registry::, as used in your Push-Location call)

What appears to be happening is that when the items are stringified - which is what happens when you pass them as a whole, as an argument (e.g. Remove-Item $filteredlist, which is the same as Remove-Item -Path $filteredlist), they lack the provider prefix and are represented as registry-native paths.

And given that a full registry-native path such as HKEY_LOCAL_MACHINE\... neither starts with a drive specification nor with \ or /, it is interpreted as a relative path, resulting in the symptom you saw.