Windows PowerShell and Long Paths

I think that you, like me, have often seen paths of the form \ !!! Important \ ____ New ____ \ !!! Do not delete !!! \ Order No. 98819-649-B dated February 30, 1985 on the appointment of Kozlov Ivan Aleksandrovich as the interim head of the department for escorting corporate VIP clients and organizing business meetings on the sidelines.doc .

And often to open such a document in Windows does not work right away. Someone practices workaround in the form of disk mapping, someone uses file managers that can work with long paths: Far Manager, Total Commander and the like. And many more sadly watched as they created a PS-script, which was a lot of work and which worked in a test environment with a bang, in a combat environment helplessly complained about an impossible task:The specified path, file name, or both are too long. The fully qualified file name must be less than 260 characters, and the directory name must be less than 248 characters.
As it turned out, 260 characters are enough "not only for everyone." If you are interested to go beyond the boundaries of what is permissible - I ask for cat.

Here are just 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 is mounted to users as a network drive S; users create files that will not be able to read admins / scripts with local access from the server, because the absolute path is longer than the network path;
• synchronization errors of roaming profiles ;
• problems recovering from shadow copies ;
• when data is migrated from other systems in which there are less stringent restrictions on the path length, 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 ...

A little 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 (unless, of course, you did everything correctly the rest ).

I would also like to draw attention to the very useful robocopy utility that helped me more than once . She, too, is not afraid of long paths, and she knows a lot. Therefore, if the task comes down to copying / transferring file data, you can stop at it. If you need to shamanize with file system access control lists (DACLs), look towards subinacl . Despite its considerable age, it showed excellent results on Windows 2012 R2. Then consider ways to apply.

It was interesting to me to teach to work with long ways PowerShell. With him almost like in a bearded anecdote about Ivan Tsarevich and Vasilisa the Beautiful.

Quick way

Go to Linux and do not steam Windows 10/2016/2019 and enable the corresponding Group Policy setting / click registry. I will not dwell on this method in detail, because there are already a lot of articles on the network on this topic, for example, this one .

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

Long way

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

For starters, update PowerShell. It is done one-two-three.

1. We are updating the .NET Framework to version no lower than 4.5. The operating system must be at least Windows 7 SP1 / 2008 R2. The current version can be downloaded here , read more information here .
2. Download and install Windows Management Framework 5.1
3. Reboot the car.

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

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



Now when using the Get-ChildItem cmdlets and the like, instead of the usual Path, we will use 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 familiar format to the LiteralPath format, you can use this 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"}
}

Please note that you cannot use wildcards ( * , ? , Etc.) when specifying the LiteralPath parameter . 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 a recursive search, I used it a couple of times and was satisfied. Now you can not be afraid that your PS-script will go astray and will not make out distant files. For example, this approach helped me a lot when writing a script for dropping the “temporary” attribute on files in DFSR folders. But this is another story, which I will try to tell in another article.




UPD 07/06/2019: Promised article I am
waiting for interesting comments from you and suggest you take a survey.

Useful links:
docs.microsoft.com/en-us/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