Question [Résolu] Get-ChildItem imprevisible

J'ai, sur mon PC, un fichier dont le chemin d'accès dépasse la taille légale (260 caractères, je crois). Il faut traverser 21 répertoires pour le trouver.
La commande MS-DOS, bien connue \"dir\" me donne l'inventaire complet du répertoire le plus profond.
En revanche, la commandelette \"Get-ChildItem\" refuse obstinément de poursuivre l'inventaire, dès l'instant où elle en est à afficher le nom du fichier fautif. Le paramètre \"-ErrorAction 'Continue'\" ou toute autre valeur n'y change absolument rien. POURQUOI?
En outre, dans une boucle du type
\"Get-ChildItem $Repertoire -Recurse | ForEach {... ...}\"
le reste du répertoire n'est pas traité.
C'est particulièrement gênant quand on veut faire une sauvegarde de tout ce $Repertoire.
COMMENT FAIRE?<br><br>Message édité par: Arnaud, à: 13/05/19 10:20

Merci de votre réponse, Laurent.

Cependant, ceci ne fait pas vraiment avancer mon problème :

- Je travaille encore sous Windows 7 professionnel, monoposte. Je n'ai pas l'option qui permet de passer aux noms très longs (1024 caractères de chemin, je crois),
- C'est plus le comportement de Get-ChildItem qui me préoccupe. Si Get-ChildItem abandonne dès la moindre erreur (et pas seulement sur un nom trop long), comment peut-on administrer correctement un système de fichiers?

J'ai probablement dû oublier un paramètre ou une notion importante de la gestion des fichiers avec PowerShell (je débute en la matière). Je voudrais bien savoir ce qui coince comme ça.

Je remercie, par avance, les expérimentés qui voudront me guider.

salut Millou et Laurent

pour complete la reponse de Laurent tu peut bien sur utilisé AlphaFS mais serait bien mieux de passer en version powershell 5.0 sur windows 7 voir ce blog
ainsi sauf erreur de ma part tu pourra utilisé une des dernieres version de powershell qui gére les chemins long et bien plus encore
sinon tu pourra utilisé le module NTFSSecurity qui contient un get-childitem2 qui gére les chemins long !!
vois ce blog pour sont installation

Merci à Laurent et à 6ratgus. Je pense, en effet, à passer à PowerShell 5.0. Ce serait certainement mieux.

En attendant, j'ai procédé à divers essais sur la commandelette \&quot;Get-ChildItem\&quot;, j'arrive aux conclusions suivantes :

- Sans le paramètre \&quot;-Force\&quot;, \&quot;Get-ChildItem\&quot; inventorie tous les fichiers d'un dossier
sauf les fichiers cachés, c'est-à-dire ceux qui ont l'attribut H. Il ne fait pas, non
plus état des fichiers dont le nom est trop long.

- Avec le paramètre \&quot;-Force\&quot;, \&quot;Get-ChildItem\&quot; inventorie tous les fichiers d'un dossier
quelques soient les attributs (A, H, S, R), mais il abandonne l'inventaire du dossier
dès le premier fichier de nom trop long rencontré, avec l'exception \&quot;PathTooLongException\&quot;.

Dans l'un comme dans l'autre cas, son comportement n'est pas satisfaisant. Toutefois, je préfère
utiliser le paramètre \&quot;-Force\&quot;, le cas d'un fichier de nom trop long pouvant être écarté facilement par
l'utilisateur sans grande conséquence. Cela me paraît plus correct que de bricoler les attributs pour
améliorer la visibilité.

Ce devrait être à Microsoft de revoir le code de \&quot;Get-ChildItem\&quot;.

Pour créer un fichier de chemin d'accès trop long ( &gt;= 260 caractères ), il ne faut pas lui
donner un nom simple (\&quot;basename\&quot; au sens Unix du terme) qui ferait dépasser la longueur du nom de son
chemin d'accès à 260 caractères (NTFS le refuse), mais seulement renommer l'un des repertoires composant
ce chemin d'accès avec un nom plus long.