Long Path Support Powershell

If you have ever had to deal with long file paths on Windows you will know that there is a limit of 260 characters. To make matters worse this limit only applies to some tools and there are plenty of situations where path lengths will go over this limit (yes roaming profile shares I am looking at you).

To work around the problem previously you had to map network drives deep into a folder structure or use a tool that did support long file paths like RoboCopy.

The good news is now PowerShell can be configured to support long paths.

How to enable long paths

As of time of writing you need to have the following two items installed:

• Windows Management Framework 5.1
• .Net Framework 4.6.2

The easiest way to get these installed is to upgrade to the Windows 10 Anniversary update.

Once installed it is a matter of updating local group policy by doing the following:

1. Click Start and type gpedit.msc

2. Browse to Computer Configuration>Administrative Templates>System>FileSystem

3. Double click on Enable Win32 long paths policy item.

4. Select Enabled and press ok.

Now the next time you start a Powershell process it will have long paths enabled.

Things to be aware of

The main thing to be aware of is other processes still have the 260 character limit issue. So don’t be surprised if you run into problems when launching external utilities from deep folder paths.

Other thing that caught me off guard is I got all excited that Explorer now supported these changes because it was able to browser some of these long folder paths too. What I didn’t realise was explorer was being clever and using the 8.3 shortname name for folders close to the root. If you try and launch explorer from Powershell at a deep structure, it will still fail.

Why is this not enabled for all Applications still?

The problem is actually a lot harder than you would initially think. The problem has boiled down to the following reasons:

• Differences in API calls. There are currently 2 api calls in Windows for opening files. The regular one that most applications use and a Unicode one which can open long paths if you put the special \\?\ notation in front of the path.

• Politics. There is a large group of people who don’t believe it is a good idea to support longer than 260 characters. They believe that it will cause users to get confused because some applications can open files in long paths while others can not. Personally I think this is a silly argument because we are already in this mess.

• Applications written on top of a framework like the .net framework are limited by what said framework supports.

.Net Support

As of .Net Core 1.0 and .Net Framework 4.6.2 long paths are supported and they also don’t require the \\?\ notation. There are however some things to be aware of.

.Net Core 1.0 will support this out of the box because it runs cross platform and other platforms are expected to support long paths.

.Net 4.6.2 on the other hand is a different story. To enable support you need to enable the group policy setting listed above and also put a special entry into your application manifest listed below.

Future

I hope in the future more and more applications start to support this entry and Microsoft will flip support on by default. I don’t see this happening any time soon though due to the large number of applications that don’t support it. However at least now we have support for Powershell which should remove most IT Pro pain caused by long paths.