Je pense que, comme moi, vous avez souvent vu des chemins tels que !!! Important____Nouveau____!!! Ne pas supprimer!!! Ordre n°98819-649-B du 30 février 1985 concernant la nomination d'Ivan Alexandrovitch Kozlov comme responsable par intérim du département d'accompagnement des clients VIP et de l'organisation de réunions d'affaires dans les coulisses.doc.
Et souvent, il n'est pas possible d'ouvrir immédiatement un tel document sous Windows. Certains pratiquent le contournement en mappant des disques, d'autres utilisent des gestionnaires de fichiers capables de gérer des chemins longs : Far Manager, Total Commander et des programmes similaires. Beaucoup ont également observé avec tristesse comment leur script PS, dans lequel ils ont investi beaucoup de travail et qui fonctionnait à merveille dans un environnement de test, se plaignait sans défense d'une tâche insurmontable en environnement de production : Le chemin spécifié, le nom de fichier ou les deux sont trop longs. Le nom de fichier complet doit contenir moins de 260 caractères, et le nom du répertoire doit contenir moins de 248 caractères.
Il s'avère que 260 caractères ne sont pas « destinés à tout le monde ». Si vous souhaitez franchir les limites autorisées, je vous invite à continuer.
Voici quelques-unes des conséquences regrettables de la limitation de la longueur du chemin de fichier :
- sur le serveur, il y a un dossier, par exemple, D:DataSharedAccounting, qui est partagé via SMB et monté pour les utilisateurs en tant que disque réseau S ; les utilisateurs créent des fichiers que les administrateurs/scripts ne pourront pas lire lors d'un accès local au serveur, car le chemin absolu devient plus long que le réseau ;
- ;
- ;
- lors de la migration des données d'autres systèmes, où les restrictions de longueur de chemin sont moins strictes, une partie de celles-ci deviendra indisponible dans le nouvel environnement sans quelques efforts ;
- ;
- etc...
En m'écartant légèrement du sujet, je note que pour la réplication DFS, le problème évoqué dans l'article n'est pas si grave et que les fichiers avec des noms longs voyagent avec succès d'un serveur à un autre (si bien sûr vous avez tout fait correctement) ).
Je voudrais également attirer votre attention sur un utilitaire très utile qui m'a souvent dépanné . Il n'a également aucun problème avec des chemins longs, et il sait faire beaucoup de choses. Donc, si la tâche consiste à copier/déplacer des données de fichiers, vous pouvez vous arrêter là. Si vous devez jouer avec les listes de contrôle d'accès dans le système de fichiers (DACL), regardez du côté de . Malgré son âge vénérable, elle a bien performé sur Windows 2012 R2. les méthodes d'application ont été examinées.
J'étais curieux d'apprendre à travailler avec des chemins longs dans PowerShell. Cela rappelle presque la vieille blague sur Ivan Tsarevitch et Vasilisa la Belle.
Méthode rapide
Passer à Linux et ne pas se soucier de Windows 10/2016/2019 et activer le paramètre correspondant dans la stratégie de groupe/tweaker le registre. Je ne vais pas m'attarder sur cette méthode, car il y a déjà beaucoup d'articles à ce sujet sur le net, par exemple, .
Étant donné qu'il y a de nombreuses versions de systèmes d'exploitation, pour le dire poliment, obsolètes dans la plupart des entreprises, cette méthode est rapide uniquement sur le papier, sauf si vous faites partie des chanceux qui ont peu de systèmes legacy et qui utilisent Windows 10/2016/2019.
Méthode longue
Précisons tout de suite que les modifications n'affecteront pas le comportement de l'explorateur Windows, mais permettront d'utiliser des chemins longs dans les cmdlets PowerShell, comme Get-Item, Get-ChildItem, Remove-Item, etc.
Pour commencer, mettons à jour PowerShell. Cela se fait en un deux trois.
- Nous mettons à jour .NET Framework à une version d'au moins 4.5. Le système d'exploitation ne doit pas être inférieur à Windows 7 SP1/2008 R2. La version actuelle peut être téléchargée , en lisant plus d'informations .
- et nous installons Windows Management Framework 5.1.
- Redémarrez la machine.
Les travailleurs acharnés peuvent effectuer les étapes décrites ci-dessus manuellement, les paresseux – à l'aide de SCCM, de politiques, de scripts et d'autres outils d'automatisation.
La version actuelle de PowerShell peut être connue à partir de la variable $PSVersionTable. Après la mise à jour, cela devrait ressembler à ceci :

Maintenant, lors de l'utilisation des cmdlets Get-ChildItem et similaires, au lieu de l'habituel Chemin Pour l'envoi d'e-mails, un hôte est nécessaire LiteralPath.
Le format des chemins sera un peu différent :
Get-ChildItem -LiteralPath "?C:Folder"
Get-ChildItem -LiteralPath "?UNCServerNameShare"
Get-ChildItem -LiteralPath "?UNC192.168.0.10Share"
Pour faciliter la conversion des chemins du format habituel au format LiteralPath vous pouvez utiliser cette fonction :
Function ConvertTo-LiteralPath
Param([parameter(Mandatory=$true, Position=0)][String]$Path)
If ($Path.Substring(0,2) -eq "") {Return ("?UNC" + $Path.Remove(0,1))}
Else {Return "?$Path"}
}
Veuillez noter que lors de la définition du paramètre LiteralPath vous ne pouvez pas utiliser de caractères génériques (*, ? etc.).
En plus du paramètre LiteralPath, dans la version mise à jour de PowerShell, le cmdlet Get-ChildItem a obtenu le paramètre Depth, qui permet de spécifier la profondeur de la recherche récursive, que j'ai utilisé quelques fois et j'en ai été satisfait.
Vous n'avez plus à craindre que votre script PS soit détourné de son long parcours semé d'embûches et qu'il ne parvienne pas à détecter des fichiers lointains. Personnellement, cette approche m'a beaucoup aidé lors de l'écriture d'un script pour supprimer l'attribut « temporaire » des fichiers dans les dossiers DFSR. Mais c'est une autre histoire, que je m'efforcerai de partager dans un autre article. Je suis également impatient de lire vos commentaires intéressants et vous invite à participer à l'enquête.
Liens utiles :
Seuls les utilisateurs enregistrés peuvent participer au sondage. , s'il vous plaît.
Le problème des chemins longs vous concerne-t-il ?
Oui
Oui, ça m'a concerné, mais j'ai déjà résolu le problème
Ça me gêne, mais pas trop
Je n'y ai pas pensé, tout semble fonctionner
Non
Autre (veuillez préciser dans les commentaires)
155 utilisateurs ont voté. 25 utilisateurs se sont abstenus.
Source : habr.com
