Table of Contents
If you're a Windows developer, system administrator or seasoned user, there's good chance you're fully aware of the 255-260 character limit of filesystem paths. However, in case you never heard about it, here's a small recap of the issue:
In the Windows API (with some exceptions discussed in the following paragraphs), the maximum length for a path is MAX_PATH, which is defined as 260 characters. A local path is structured in the following order: drive letter, colon, backslash, name components separated by backslashes, and a terminating null character. For example, the maximum path on drive D is "D:\some 256-character path string<NUL>" where "<NUL>" represents the invisible terminating null character for the current system codepage. (The characters < > are used here for visual clarity and cannot be part of a valid path string.) [extract from this MSDN official guide].
If you're a standard user, chances are you won't get bothered by this limitation: who needs these long paths anyway? However, if you happen to be a developer working with linux-native package managers such as NPM, you will be struck by that issue sooner or later. That's because there are many popular script-based libraries which make an intensive use of folder-nesting: AngularJS, Angular2, React and SystemJS, just to throw out some good examples. If you use them with Visual Studio 2015, which will adds their solution/project folder structure to the loop, the chance of hitting that limit will be even higher.
As soon as this happens your system will be unable to properly access these files and you'll face a number of frustrating issues: Visual Studio crashes, build errrors, IIS errors and more. The scenario will be even worse if you're using task runners or other tools to automate IO tasks for debug and/or release purposes, because they will also be unable to read, move, copy, delete or do any kind of work within these path, throwing a number of exceptions that will most certainly give you more than an headache.
This is a common example of an error related to the 255-260 characters limit being hit (from the Visual Studio crash log):
1 2 3 4 5 |
---> (Inner Exception #1) System.InvalidOperationException: The item metadata "%(FullPath)" cannot be applied to the path "<very long path here>". <very long path here> at Microsoft.Build.Shared.ErrorUtilities.ThrowInvalidOperation(String resourceName, Object[] args) at Microsoft.Build.Shared.ErrorUtilities.VerifyThrowInvalidOperation(Boolean condition, String resourceName, Object arg0, Object arg1, Object arg2) at Microsoft.Build.Shared.FileUtilities.ItemSpecModifiers.GetItemSpecModifier(String currentDirectory, String itemSpec, String definingProjectEscaped, String modifier, String& fullPath) at Microsoft.Build.Evaluation.BuiltInMetadata.GetMetadataValueEscaped(String currentDirectory, String evaluatedIncludeBeforeWildcardExpansionEscaped, String evaluatedIncludeEscaped, String definingProjectEscaped, String name, String& fullPath) |
And this is a standard "Visual Studio has crashed" popup warning that you might get for the same reason:
Now that we successfully identified the issue, let's see what workarounds we can use to overcome this.
Option #1: Make your base path shorter
It might sound obvious, but it's entirely possible that you can fix your issue by shorten your base path. You cannot easily change the NPM packages folder structure (you should never do that), yet you can always move your project to a different location on your hard drive.
For example, if you keep your solution in
C:\Users\<Your Username>\Documents\Visual Studio 2015\Solutions\, you can easily move everything to
C:\Solutions\and shorten all your project paths by a good amount of characters.
Option #2: Enable the NTFS/Win32 long paths policy
If you don't want to mess up your working paths you can also use a good alternative, assuming you're using Windows 10: enable the NTFS long paths policy (or Win32 long paths policy, depending on the Windows 10 build) and get rid of these limits for good.
According to Microsoft, "enabling NTFS/Win32 long paths allows manifested win32 applications and Windows Store applications to access paths beyond the normal 260 char limit per node."
This is precisely what we need, isn't it? Enable this feature isn't hard, but it will require us to make some edits to the Windows Group Policies using the Group Policy editor. These are the required steps:
Before Anniversary Update
If you're running a Windows 10 build between 14352 and RTM 1607, aka "Anniversary Update", you need to do the following:
- Launch the Group Policy Editor by pressing Windows Key and manually typing gpedit.msc, then hit the Enter key.
- Navigate to Local Computer Policy > Computer Configuration > Administrative Templates > System > Filesystem > NTFS.
- Locate the Enable NTFS long paths option and enable it with a click.
As an alternative, you can also achieve the same results by executing the following registry commands:
1 2 3 4 5 6 7 |
Windows Registry Editor Version 5.00 [HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\FileSystem] "LongPathsEnabled"=dword:00000001 [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem] "LongPathsEnabled"=dword:00000001 |
After Anniversary Update
If you're running a post-Anniversary Update Windows 10 build (RTM 1067 or newer), you need to use the following:
- Launch the Group Policy Editor by pressing Windows Key and manually typing gpedit.msc, then hit the Enter key.
- Navigate to Local Computer Policy > Computer Configuration > Administrative Templates > System > Filesystem.
- Locate the Enable Win32 long paths option and enable it with a click.
This should fix your issue for good.
Option #3: Modify your Windows Registry File
If you don't want to mess with the Group Policy editor, you can use this alternative method and apply the relevant changes directly on your Windows registry file.
- Launch regedit.exe from a command-prompt or using the Run app.
- Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem
- Add a new DWORD key and call it LongPathsEnabled - if such key already exists, skip this step.
- Give the LongPathsEnabled DWORD key a value of 1 to Enable the long file names support.
- Reboot your system.
A great advantage of this method is the fact that it works even with non-pro editions of Windows 10, such as Windows 10 Home - where the Local Group Policy Editor is not available.
It goes without saying that, in order to have such feature disabled, you'll just have to open your Windows registry file again and delete that key.
Conclusion
That's it for now: we hope that this small guide will help those who are struggling to enable the support for long file pathnames on their Windows 10 system.