🥇Windows, PowerShell and long paths

I believe, like me, you've often encountered paths like !!! Important____New____!!! Do not delete!!! Order No. 98819-649-B from February 30, 1985, on the appointment of Ivan Alexandrovich Kozlov as the acting head of the department for supporting corporate VIP clients and organizing business meetings in the corridors.doc.

And often you won't be able to open such a document in Windows right away. Some practice workarounds like mapping drives, while others use file managers that can handle long paths: Far Manager, Total Commander, and similar tools. Many have also sadly watched as their carefully crafted PS script, which worked flawlessly in the test environment, helplessly complained about an insurmountable task in production: 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.
It turns out that 260 characters are not sufficient for everyone. If you're interested in crossing the allowable limits — please read more.

Here are just a few of the unfortunate consequences of the file path length limitation:

there's a folder on the server, for example, D:DataSharedAccounting, which is shared via SMB and mounted for users as network drive S; users create files that administrators/scripts won't be able to read with local access from the server since the absolute path ends up being longer than the network path;
synchronization errors for migrated profiles;
issues when restoring from shadow copies;
when migrating data from other systems with less strict path length restrictions, some of them will become inaccessible in the new environment without a workaround;
incorrect data when calculating sizes and numbers of files in folders;
etc…

A bit off-topic, but I’d like to point out that for DFS Replication, the problem discussed in the article is not a concern, and files with long names successfully travel from server to server (if, of course, you did everything else right) correctly done).

I would also like to highlight a very useful utility that has saved me on numerous occasions robocopy. It is also not afraid of long paths, and it can do a lot. Therefore, if the task is to copy/move file data, you can rely on it. If you need to tinker with the Discretionary Access Control Lists (DACL), take a look at subinacl. Despite its considerable age, it has performed excellently on Windows 2012 R2. Here methods of application will be discussed.

I was curious to teach how to work with long paths in PowerShell. It's somewhat like the old joke about Ivan Tsarevich and Vasilisa the Beautiful.

A quick way

is to switch to Linux and not worry about Windows 10/2016/2019, and enable the corresponding group policy/tweak the registry. I won’t go into detail on this method, as there are already many articles on this topic online, for example, this.

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

A long way

It's worth noting that the changes will not affect the behavior of Windows Explorer, but will allow the use of long paths in PowerShell cmdlets such as Get-Item, Get-ChildItem, Remove-Item, and others.

First, let's update PowerShell. It can be done in no time at all.

We update the .NET Framework to a version no lower than 4.5. The operating system must be at least Windows 7 SP1/2008 R2. You can download the current version here, read additional information here.
Download and install Windows Management Framework 5.1
Restart the machine.

Diligent users can perform the steps described above manually, while the lazy can do it via SCCM, policies, scripts, and various other automation tools.

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

Now, when using cmdlets Get-ChildItem and similar ones, 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 "?UNCServerNameShare"
Get-ChildItem -LiteralPath "?UNC192.168.0.10Share"

For convenience, to convert 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"}
}

Note that when specifying the parameter LiteralPath wildcards cannot be used (*, ? etc.).

In addition to the parameter LiteralPath, the updated version of PowerShell has introduced the commandlet Get-ChildItem which received the parameter Depth, allowing you to specify the nesting depth for recursive searches. I used it a couple of times and was very satisfied.

Now you don't have to worry that your PS script will get lost on a long winding path and miss distant files. This approach, for example, helped me a lot when writing a script to remove the 'temporary' attribute from files in DFSR folders. But that's another story, which I will try to share in another article. I look forward to your interesting comments and invite you to participate in the 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

Only registered users can participate in the survey. Please log in, please.