While NTFS allows paths some 32,000 characters long, you've found the 259-character path length limitation of the Win32 API.
In the Windows API (with some exceptions discussed in the [linked document]), the maximum length for a path is MAX_PATH
, which is defined as 260 characters.
(There is additionally a NULL
termination character appended to the path, giving us 259 usable characters.)
Because Explorer (and almost all other Windows apps) rely on the Win32 API for filesystem access, it's not practical to get around this limitation even though it is possible:
The Windows API has many functions that also have Unicode versions to permit an extended-length path for a maximum total path length of 32,767 characters. This type of path is composed of components separated by backslashes, each up to the value returned in the lpMaximumComponentLength
parameter of the GetVolumeInformation
function (this value is commonly 255 characters). To specify an extended-length path, use the "\\?\" prefix. For example, "\\?\D:\very long path".
Unfortunately, you can't just type \\?\D:\very long path
in to an Explorer window. The application must be designed to take advantage of these APIs and handle very long path names.
One way to access extended-length paths under Windows is to install Cygwin, a *nix emulation layer for Windows. In my testing, Cygwin does not appear to be limited by MAX_PATH
; bash and vi had no problems with paths 2,000 characters long.
Keep in mind that even though you can use bash to browse extended-length paths, you probably won't be able to open files in those paths in regular Windows applications. For example, typing notepad
while the working directory is an extended-length path gets you
Error: Current working directory has a path longer than allowed for a Win32 working directory. Can't start native Windows application from here.
And trying notepad "\\?\D:\very long path\file.txt"
doesn't work either; it launches, but just says
"Can't find file ..." Trying the same with Notepad++ crashes it. (Probably a buffer overflow.)
Your other option to access specific files buried deep within an extended-length path is to shorten the path itself by creating a NTFS junction point. From an elevated command prompt:
D:\> mklink /J jct "\\?\D:\very\long\path"
You can now access the contents of D:\very\long\path\
from D:\jct\
. You won't hit any path length problems because as far as Explorer and other apps are concerned, the path is just D:\jct\
(or whatever). The NTFS driver handles redirecting the path (the "reparse point") transparently.
The downside to this approach is obviously that you have to create a junction near the file you want to access; you still can't simply browse the entire directory structure.
Regarding special characters (" * : < > ? \ |
), that's simply a no-go. Those characters have special meanings within Windows, so it's not possible to use them within paths. (Cygwin allows you to create files with special characters, but it does so by substituting the characters with special Unicode characters, which it then substitutes back when reading. Viewing these Cygwin-created files under Linux or in Explorer wouldn't look right, since the Unicode characters wouldn't be substituted back.)
All of that said, what are you doing that requires very long paths? Perhaps you could make your life easier by reevaluating what you're doing and avoiding long paths. Chances are, you don't need paths that long anyway.