260 character Explorer path length limit

Question

Hello,

I am trying to understand whether the 260 character MAX_PATH limitation described in the following link can be circumvented. The link talks about getting around that limitation when using particular API calls as a developer. However, I am trying to get around that limitation using Explorer interactively, manually, without code. (So apologies if I am not really posting in the correct forum.) Does anyone know if you can manually create paths longer than the MAX_PATH limit?

https://msdn.microsoft.com/en-us/library/aa365247%28VS.85%29.aspx?f=255&MSPPError=-2147217396#maxpath

Here is another related article:

https://mspoweruser.com/ntfs-260-character-windows-10/

Many thanks.

Keith

---

R K Howard

Answer 1

Hi,

I don't recommend to do for compatibility with other software, but you can change the max length of path:

(1) run regedit.exe as administrator
(2) locate [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem]
(3) change data value [LongPathsEnabled] (DWORD) to "1"
(4) close regedit and restart Windows

[note] this can be applied to Windows 10. 
______________
Ashidacchi

Answer 2

Hi,

Thank you for posting here.

For changing the limitation of path length. the link you provide has provided two methods.

1.

A registry key allows you to enable or disable the new long path behavior.

To enable long path behavior set the registry key at  HKLM\SYSTEM\CurrentControlSet\Control\FileSystem LongPathsEnabled (Type: REG_DWORD). 

The registry key will not be reloaded during the lifetime of the process. In order for all apps on the system to recognize the value of the key, a reboot might be required because some processes may have started before the key was set.

The registry key can also be controlled via Group Policy at

Computer Configuration > Administrative Templates > System > Filesystem > Enable NTFS long paths.

2.

You can also enable the new long path behavior per app  via the manifest.

<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>

Best Regards,

Hart

---

Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact [e-mail].

Answer 3

Thank you for the replies so far. I knew about the registry key hack, but I was too scared to try it, so far. What I am really trying to understand is what will be the impact on my daily usage of Windows, both as a user and as a developer.

As a user, will I then be able to create paths that are, say, 1,000 characters in length? If so, will there be any other impact on me as a user? Is there any best practice guidance from MS?

Also, as a developer, I automate Explorer. I wrote an Explorer shell that iterates through all Word (.docx) files on my network, opening them one at a time, and performing an operation on them within Word. Will this still work if the Word documents are located at a lower point than 260 characters in the folder structure.

Thanks for the help.

Keith

---

R K Howard

Answer 4

Hi R.Keith Howard,

In advance, sorry, I misunderstand your issue and standpoint.

If you are scared to modify registry, you should not make too long path.
It might have a bad effect on your users (they must face the same issue as you).
____________
Ashidacchi

Answer 5

Sorry, I think I did not express my point properly. I am not scared about the registry. I understand a lot about the registry. I have modified it in the past. For the purpose of my question, please treat me as the only user. I am a power user and a developer. But still, I do not fully understand what the behaviour will be like when I make this change, so I repeat my above questions.

Many thanks.

Keith

---

R K Howard

Answer 6

From a development perspective relying on the new functionality will affect application compatibility with Win7/8.1.

As far as Win10 is concerned I suggest you activate the long path support in a virtual machine and do some testing.

Answer 7

Yes, RLWA32,

It's true that an agonizing decision exists whether the long pass used or not.
But I'd like to make a choice of legacy way. (over sixty-years-young developer) 

Answer 8

Since the OP mentioned opening Word documents on a network testing might be appropriate to determine how Win10 long path support is handled over a network.  The documentation that I have seen does not specifically mention how this is handled.  For example -

Will networking on a server (long path support enabled) honor long paths?

What if a remote drive is on a Win10 system for which long path support is not enabled?

What if the remote drive is on system other than Win10 e.g., Win7/8.1 or even Linux?

Answer 9

Fun fact, the documentation on MSDN is wrong.

The first link you linked to stated that you must either enable the registry key or enable the group policy (which basically sets the registry key) or manifest the application. Well, on my system which has been updated to Creators Update, enabling the group policy/setting the registry value to 1 doesn't allow explorer to create paths longer than 260 characters in length.

Yes I actually had explorer show that message. Also, to show the longest path that I could get explorer to create, here is what it looks like in the console.

If instead of setting the registry key, you go to the group policy settings instead, the description is:

"Enabling Win32 long paths will allow manifested win32 applications and Windows Store applications to access paths beyond the normal 260 character limit per node on file systems that support it.  Enabling this setting will cause the long paths to be accessible within the process."

Well, yes you could mistake this to be any application with a manifest (i.e. all of them these days), but if you remember that explorer doesn't allow the creation of paths longer than 260 characters even with that enabled, then the only option is that you need both to be able to access paths longer than 260 characters using the raw path in the filesystem functions.

So let's look at the manifest for explorer.

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<!-- Copyright (c) Microsoft Corporation -->
<!--
    This is the manifest file only for Explorer.
    It only differs from windowsshell.manifest in the <dpiAware> tag.
-->
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
    name="Microsoft.Windows.pcshellshell.explorer"
    processorArchitecture="amd64"
    version="5.1.0.0"
    type="win32"/>
<description>Windows Shell</description>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            processorArchitecture="*"
            publicKeyToken="6595b64144ccf1df"
            language="*"
        />
    </dependentAssembly>
</dependency>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
    <security>
        <requestedPrivileges>
            <requestedExecutionLevel level="asInvoker" uiAccess="false"/>
        </requestedPrivileges>
    </security>
</trustInfo>
<application xmlns="urn:schemas-microsoft-com:asm.v3">
    <windowsSettings>
        <dpiAware xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">Explorer</dpiAware>
    </windowsSettings>
</application>
</assembly>

There is no longPathAware element in the manifest. This explains why explorer can't access paths longer than 260 characters.

TL;DR

This isn't a one or another thing, you need both the registry key setting set to 1/group policy setting enabled and have the application manifest contain the longPathAware setting to get an application to ignore the 260 character limit. Explorer doesn't have the manifest entry, so it still sticks to the 260 character path limit.

---

This is a signature Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

Answer 10

Almost forgot, the console can create paths longer than 260 characters. The problem is that explorer can't handle them properly, so it switches to the short path names in this case. Well, it tries.

---

This is a signature Any samples given are not meant to have error checking or show best practices. They are meant to just illustrate a point. I may also give inefficient code or introduce some problems to discourage copy/paste coding. This is because the major point of my posts is to aid in the learning process.

Answer 11

Thank you Darran! I think I need a couple of days to digest all of that. Let me ponder, and I will come back.

Bye for now.

Keith

P.S. Somehow, I am left with the feeling that I am going to regret going down this track! :) But, I've been battling this limitation for years.

---

R K Howard

Answer 12

As an alternative, fast and dirty workaround - you can map a drive letter to a directory in the tree, starting from which all paths are < MAX_PATH (use subst command) or  create a symbolic link.

-- pa

Answer 13

Hi, 

A bit late, but amazing answer. 

Question though... Where can I find these manifest ?
I'd like to see those for cmd.exe and powershell. 
There are post where we can see people making path greater than 9000 chrs. I can't 
https://serverfault.com/questions/847142/cant-use-long-path-names-in-windows-2016

regards 

Answer 14

> Where can I find these manifest ? I'd like to see those for cmd.exe and powershell. 

You can open cmd.exe from Visual Studio 2017. Use "Open with..." and select "Resource editor".

Then look at the RT_MANIFEST resource. 

(spoiler:  both have longPathAware=true)

-- pa