Windows PowerShell and Long Paths

I think you, like me, more than once had to see the ways of the form \ !!! Important \ ____ New ____ \ !!! Do not delete !!! \ Order number 98819-649-B of February 30, 1985. on the appointment of Kozlov Ivan Aleksandrovich as acting head of the direction for the maintenance of corporate VIP-clients and the organization of business meetings on the sidelines.doc .

And often to open such a document in Windows immediately fail. Someone practices workaround in the form of disk mapping, someone uses file managers who can work with long paths: Far Manager, Total Commander and the like. And many more sadly observed how the PS-script they created, which invested a lot of work and which in the test environment worked with a bang, in the combat environment helplessly complained about the overwhelming task: The specified path, file name, or both are too long . It must be less than 248 characters.
As it turned out, 260 characters will suffice "not only for everyone." If it is interesting to you to go beyond the limits of what is permitted, I ask for cat

Here are some of the sad consequences of limiting the length of a file path:
')

• there is a folder on the server, for example, D: \ Data \ Shared \ Accounting, which is shared via SMB and mounted to users as a network drive S; Users create files that admins / scripts cannot read when they are locally accessed from the server, since the absolute path is longer than the network;
• synchronization errors of roaming profiles ;
• problems with recovering from shadow copies ;
• when migrating data from other systems in which there are less stringent restrictions on the length of the path, in a new environment, some of them will become inaccessible without dancing with a tambourine;
• Incorrect data when calculating the size and number of files in folders ;
• etc ...

Slightly deviating from the topic, I note that for DFS Replication, the problem considered in the article is not terrible and files with long names successfully travel from server to server (if, of course, you did everything right for the rest).

I would also like to draw attention to the very useful and not just rescuing utility robocopy . She, too, is not afraid of long ways, and she knows how much. Therefore, if the task is reduced to copying / transferring file data, you can stop there. If you need to pochamanit with access control lists in the file system (DACL), look in the direction of subinacl . Despite its age, it showed itself perfectly on Windows 2012 R2. Here considered methods of application.

I was also interested in learning how to work with long paths in PowerShell. He is almost like a bearded joke about Ivan Tsarevich and Vasilisa the Beautiful.

Quick way

Switch to Linux and do not bathe in Windows 10/2016/2019 and enable the corresponding Group Policy setting / tweak the registry. I will not dwell on this method in detail, because There are already many articles on this topic on the web, for example, this one .

Considering that in most companies there are many, to put it mildly, not fresh versions of operating systems, this method is fast only for writing on paper, unless, of course, you are not one of the lucky ones who have little legacy systems and reign Windows 10/2016/2019 .

Long way

Here we will immediately make a reservation that the changes will not affect the behavior of Windows Explorer, but will allow you to use long paths in PowerShell cmdlets, such as Get-Item, Get-ChildItem, Remove-Item, etc.

To get started, update PowerShell. It is done on one-two-three.

1. We are updating the .NET Framework to version 4.5 and higher. The operating system must be at least Windows 7 SP1 / 2008 R2. You can download the latest version here , read more here .
2. Download and install Windows Management Framework 5.1
3. Reboot the machine.

Hardworking can do the steps described above manually, lazy - with the help of SCCM, policies, scripts and enikey other automation tools.

The current version of PowerShell can be found in the $ PSVersionTable variable. After the upgrade should be something like this:



Now when using Get-ChildItem cmdlets and others like it, instead of the usual Path, we will use the LiteralPath .

The format of the paths will be slightly different:

Get-ChildItem -LiteralPath "\\?\C:\Folder" Get-ChildItem -LiteralPath "\\?\UNC\ServerName\Share" Get-ChildItem -LiteralPath "\\?\UNC\192.168.0.10\Share" 

For the convenience of converting paths from the usual format to the LiteralPath format, you can use the following function:

 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"} } 

Note that when you specify the LiteralPath parameter, you cannot use wildcard characters ( * , ? , Etc.).

In addition to the LiteralPath parameter, in the updated version of PowerShell, the Get-ChildItem cmdlet received the Depth parameter, with which you can set the nesting depth for the recursive search, I used it a couple of times and was satisfied.

Now you can not be afraid that your PS script will get off the long, thorny path and will not make out distant files. For example, I was very much rescued by this approach when writing a script to drop the “temporary” attribute on files in DFSR folders. But this is another story, which I will try to tell in another article. From you I look forward to interesting comments and suggest to take a survey.

Useful links:
docs.microsoft.com/ru-ru/dotnet/api/microsoft.powershell.commands.contentcommandbase.literalpath?view=powershellsdk-1.1.0
docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/get-childitem?view=powershell-5.1
stackoverflow.com/questions/46308030/handling-path-too-long-exception-with-new-psdrive/46309524
luisabreu.wordpress.com/2013/02/15/theliteralpath-parameter