Comment se débarrasser d'un dossier « WindowsPowerShell » dans mon dossier « Documents »

J’ai récemment remarqué un dossier WindowsPowerShell dans mon dossier Documents (dans C:\Users\sylva\Documents, sylva étant mon profil utilisateur). Je l’ai supprimé, mais il revient après chaque démarrage.

S’il vous plaît, pourriez-vous m’aider à me débarrasser de ce dossier ?

Pour contexte, je n’utilise pas / n’ai pas besoin de PowerShell, donc je ne suis pas trop sûr de pourquoi ce dossier est là.

Bien que le sous-dossier WindowsPowerShell[1] du dossier Documents bien connu :[2]

soit utilisé par Windows PowerShell (l’édition héritée, livrée avec Windows, uniquement Windows, dont la dernière et ultime version est la 5.1), à savoir pour stocker des fichiers de profil de niveau utilisateur optionnels et des modules,

son existence n’est pas nécessaire au fonctionnement de Windows PowerShell, et Windows PowerShell ne le crée pas à la demande (il n’est créé que par une action délibérée de l’utilisateur).[3]

Ce qui précède implique que dans votre cas, un processus qui s’exécute à la connexion doit recréer ledit dossier, vous devrez donc enquêter pour trouver lequel.

L’utilitaire Sysinternals Autoruns peut vous aider à cet égard.

Plus précisément, étant donné que, comme vous l’indiquez dans un commentaire ultérieur, les sous-dossiers Scripts\InstalledScriptInfos sont créés à l’intérieur du dossier WindowsPowerShell indésirable, recherchez une tâche de démarrage PowerShell qui appelle Install-Module et/ou Install-Script.

Mise à jour :

Vous rapportez que le coupable s’est avéré être le gestionnaire de paquets méta à interface graphique UniGetUI

… et que la création inattendue du dossier a été signalée auparavant, dans le ticket GitHub #2098, qui, cependant, a été fermé, en raison de l’idée fausse que le dossier fait partie intégrante et nécessaire de Windows PowerShell.

(En aparté : ce qui précède pourrait indiquer que ce n’était pas nécessairement un redémarrage / une reconnexion en soi qui a causé la création du dossier, mais le lancement de l’application UniGetUI – sauf si ce lancement se produit comme tâche de démarrage.)

[1] Notez que PowerShell (Core) 7, l’édition successeur moderne, multiplateforme, à installer à la demande, utilise le sous-dossier PowerShell à la place. Le reste de cette réponse s’applique de manière analogue.

[2] Son emplacement par défaut est $env:USERPROFILE\Documents, mais il peut être redirigé vers un emplacement différent sur une machine donnée, souvent vers OneDrive ; utilisez [Environment]::GetFolderPath('MyDocuments') pour déterminer l’emplacement réel.

[3] Les actions délibérées telles que la création forcée du fichier vers lequel pointe $PROFILE avec New-Item -Force $PROFILE, qui crée implicitement son dossier hébergeant, c’est-à-dire WindowsPowerShell sous Documents (ATTENTION : si vous exécutez ceci et qu’il y a un fichier préexistant à cet emplacement, il sera tronqué) ou telles que l’installation d’un module ou d’un script avec Install-Module ou Install-Script.

Inversement, vous pouvez vérifier que le dossier n’est pas (re)créé à la demande comme suit : si nécessaire (seulement si vous observez la création inattendue du dossier), créez un nouvel utilisateur et connectez-vous en tant que tel. Si le dossier existe sur votre système, renommez-le temporairement. Puis redémarrez votre système et lancez Windows PowerShell : il démarrera normalement, sans se plaindre, et le dossier ne sera pas (re)créé.