Choose a long way (or goodbye MAX_PATH)

Many PC users running Windows, let alone developers, are familiar with problems when working with long (over 260 characters, MAX_PATH) file or directory paths.

This article discusses ways to get rid of this remnant when developing applications on various platforms (WinApi, .Net Framework, .Net Core) and activating native support for long paths in Windows 10 (Anniversary Update).

Win API applications

In applications that use the Win API for working with files, the recipe for getting rid of the MAX_PATH restriction was known from time immemorial — you had to use the Unicode version of the function with the ending “W” to work with the directory or file and start the path with the \\? \ Prefix. This made it possible to use paths up to 32767 characters.
')
In Windows 10 (1607), the behavior of the functions for working with files has changed: it is now possible to disable the check of the MAX_PATH constraints at the system level.


This eliminates the need to use the prefix \\? \ And potentially gives a chance to applications that work directly or indirectly through the Win API to get support for long paths without the need to rebuild them. How to activate this feature is described at the end of the article.

.Net Framework

Although the .Net Framework uses the Win API for working with files, the previous change would not have been successful, since BCL code contains preliminary checks on the admissibility of the lengths of the names of directories and files, and it didn’t even get to the call of the Win API functions, producing a known exception. Due to numerous requests from the community (more than 4500 on UserVoice), in version 4.6.2, the BCL code cut out the constraints on the path length, giving it to the operating system and file systems!

Here is what it gives:

• When using the prefix “\\? \” We can work with long paths as in the Win API,

  Directory.CreateDirectory("\\\\?\\" + long_dir_name); 

• If you activate native support for long file names Windows 10 (1607), then you do not even need to use the prefix!

How to turn on:

• Use .Net Framework 4.6.2 as a target when building an application.
• Use the configuration file, for example, if the application has already been built under .Net 4.0:

 <?xml version="1.0" encoding="utf-8"?> <configuration> <startup> <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/> </startup> <runtime> <AppContextSwitchOverrides value="Switch.System.IO.UseLegacyPathHandling=false;Switch.System.IO.BlockLongPaths=false" /> </runtime> </configuration> 

.Net Core

Here support for long paths was announced back in November 2015. Apparently, the open source nature of the project and the absence of the strict need to ensure backward compatibility affected it.

How to turn on:
Everything works out of the box. Unlike the implementation in the .Net Framework - there is no need to add the prefix “\\? \” - it is added automatically if necessary.

Here you can see an example.

How to enable long path support in Windows 10 (1607)

This feature is disabled by default. This is explained by the fact that this function is experimental, and there is a need to refine various subsystems and applications for full support.

You can enable built-in support for long paths by creating or changing the following registry key: HKLM \ SYSTEM \ CurrentControlSet \ Control \ FileSystem The parameter LongPathsEnabled (Type: REG_DWORD) 1 - corresponds to the value enabled.



Or through group policies (Win + R \ gpedit.msc) Computer Configuration> Administrative Templates> System> Filesystem> Enable NTFS long paths. It is also in the localized version: Computer Configuration> Administrative Templates> System> File System> Enable Win32 Long Paths.



Further sources disagree on the manifesto (or I misunderstood, but at the moment I have no opportunity to check). For example, the MSDN documentation says that the manifest can be used as an alternative way to activate support for long paths in individual applications, and the MSDN blog indicates that this is the second mandatory step after activation in policies.
But they converge in the format of setting this option:

 <application xmlns="urn:schemas-microsoft-com:asm.v3"> <windowsSettings xmlns:ws2="http://schemas.microsoft.com/SMI/2016/WindowsSettings"> <ws2:longPathAware>true</ws2:longPathAware> </windowsSettings> </application> 

With CMD, unfortunately, it will not work, at the moment, due to the peculiarities of working with paths, but in PowerShell it should work.

PS

This is where my little Friday post ends, leaving out the issues of completeness of long-path support in Windows 10 (1607), or performance when using various combinations of Windows editions, file systems, and APIs. As new facts and experimental results become available, the post will be updated.

Thanks for attention!