Utiliser Powershell pour supprimer ShellIconOverlayIdentifiers sur Windows

Question 1

Actuellement, je suis très agacé par Dropbox et Nextcloud, qui combat le ShellIconOverlayIdentifier liste. Un problème que beaucoup de gens semblent avoir, lorsque vous naviguez sur internet.

Maintenant, je veux combiner mon ennui avec mon intention d'apprendre powershell (7.2.0).

J'ai commencé avec le script suivant, qui doit récupérer toutes les clés. Et plus tard je veux utiliser les regex par -match pour trouver les entrées que je veux supprimer. Pour l'instant je travaille avec les deux Remove-Item -WhatIf et Get-ItemProperty pour le tester.

Actuellement, mon problème est que je peux créer ma liste comme prévu. Mais quand je me nourris de la liste dans la commande remove-je obtenir que le chemin ne peut pas être trouvé. Ce que je fais mal?

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

L'erreur est 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. Apparemment, il ajoute le chemin d'accès en tant que chemin d'accès relatif à l'emplacement actuel. Pourquoi ne pas l'interpréter comme un chemin absolu? Quand j'ai omettre le push-emplacement de la partie, il essaye d'ajouter le chemin d'accès du registre de mon répertoire de travail actuel dans lequel le script vie. Mais c'est faux aussi.

Merci pour votre aide à l'avance.

Question 2

Utilisez l'une des opérations suivantes:

$filteredList | Remove-Item -WhatIf -Recurse

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

Les commandes ci-dessus vous assurer que les éléments de registre (clés) sont liés par leur plein, fournisseur qualifié chemins de Remove-Item's -LiteralPath paramètre, par l'intermédiaire de leur .PSPath de propriété; dans le cas des chemins de registre, le chemin d'accès du fournisseur de préfixe est Microsoft.PowerShell.Core\Registry:: (ou, si l'identification de l'origine d' un module n'est pas nécessaire d' Registry::, utilisé dans votre Push-Location d'appel)

Ce qui semble se passer, c'est que lorsque les articles sont stringified - qui est-ce qui se passe quand vous les transmettre, comme un tout, comme un argument (par ex. Remove-Item $filteredlist, qui est le même que Remove-Item -Path $filteredlist), ils manquent de fournisseur de préfixe et sont représentées sous forme de registre indigènes chemins.

Et étant donné qu'un registre complet indigènes chemin comme HKEY_LOCAL_MACHINE\... ni démarre avec une spécification de lecteur , ni avec \ ou /, il est interprété comme une relative chemin, résultant dans le symptôme que vous avez vu.

mklement0 · Answer 1 · 2021-11-16T21:21:42

Utilisez l'une des opérations suivantes:

$filteredList | Remove-Item -WhatIf -Recurse

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

Les commandes ci-dessus vous assurer que les éléments de registre (clés) sont liés par leur plein, fournisseur qualifié chemins de Remove-Item's -LiteralPath paramètre, par l'intermédiaire de leur .PSPath de propriété; dans le cas des chemins de registre, le chemin d'accès du fournisseur de préfixe est Microsoft.PowerShell.Core\Registry:: (ou, si l'identification de l'origine d' un module n'est pas nécessaire d' Registry::, utilisé dans votre Push-Location d'appel)

Ce qui semble se passer, c'est que lorsque les articles sont stringified - qui est-ce qui se passe quand vous les transmettre, comme un tout, comme un argument (par ex. Remove-Item $filteredlist, qui est le même que Remove-Item -Path $filteredlist), ils manquent de fournisseur de préfixe et sont représentées sous forme de registre indigènes chemins.

Et étant donné qu'un registre complet indigènes chemin comme HKEY_LOCAL_MACHINE\... ni démarre avec une spécification de lecteur , ni avec \ ou /, il est interprété comme une relative chemin, résultant dans le symptôme que vous avez vu.

Merci pour l'explication élaborée. Les deux variantes de travail. En fait, je suis venu avec une troisième solution. Pourriez-vous ajouter à votre réponse, donc nous avons ici toutes les options? foreach ($item in $filteredList) {Remove-Item -WhatIf -Recurse Registry::$item}. En fait, je commençais à comme Powershell. Mais étant donné que ma version n'a pas de travail, mais votre première solution proposée ne, me fait me demander.
Merci pour l'acceptation, Gunter; je suis heureux de l'explication a été utile. Honnêtement, étant donné que les solutions de la réponse sont plus concis (pas de boucle) et plus rapide qu'un foreach-boucle de solution, je ne pense pas que le dernier est utile d'ajouter. Oui, il n'est pas évident pourquoi $filteredList | Remove-Item -WhatIf -Recurse œuvres (voir cette réponse), et les bizarreries sur la transmission de chemins peut être frustrant. Mais, malgré tous ses verrues, PowerShell a beaucoup à offrir.
Merci pour l'autre lien. Je vois que j'ai à apprendre un peu à comprendre comment les applets de commande Powershell sont en fait de traitement de l'information. Et aussi merci de remarquer que la boucle solution serait effectivement plus lent. En effet, Powershell a beaucoup à offrir. Actuellement, je l'aime vraiment, pour l'automatisation des trucs, qui a pris quelques clics autrement (à redémarrer les services, de supprimer les entrées de registre, le redémarrage de explorer.exe). J'attends donc un amour-haine-relation avec powershell pour l'instant :-)

Utiliser Powershell pour supprimer ShellIconOverlayIdentifiers sur Windows

La question

La meilleure réponse

Dans d'autres langues

Cette page est dans d'autres langues

Populaires dans cette catégorie

Questions populaires dans cette catégorie