Removing the `MAX_PATH` restriction on paths applies only to paths

Raymond Chen

A customer was playing around with Windows long paths and found that even though they used the \\?\ long path prefix, they still couldn’t use a long path.

The documentation on the maximum path limitations say that the \\?\ prefix is always available. Just to make sure, they set the registry key and created the corresponding manifest entry to enable long paths without the \\?\ prefix, but that didn’t help.

They wanted to know what they were doing wrong and included a short program to demonstrate.

The path in their sample program was C:\looooooooo⟦ 1000 more o's ⟧ooong.txt. This is well under the 32,767 limit,¹ so why doesn’t it work?

Although the \\?\ prefix and the long path setting raise the path limit to 32,767 characters, the length of each individual component of the path is also subject to a length limit. You can query this limit by calling GetVolumeInformation and checking the maximum component length. Values you might see include 255 (exFAT, NTFS), 110 (Joliet CD-RW in Unicode mode), and for network volumes, it’s determined by the network protocol.

In the customer’s case, they were passing a file name that was over 1000 characters long, which probably exceeded the maximum component length.

They can try again by using a path with longer individual components, where each one is only 100 (say) characters long, but which collectively add up in length to something greater than MAX_PATH (260).

¹ Note that the 32,767 limit includes any expansion that occurs during internal processing, so the practical limit for applications is a bit less than that.

Author

Raymond Chen

Raymond has been involved in the evolution of Windows for more than 30 years. In 2003, he began a Web site known as The Old New Thing which has grown in popularity far beyond his wildest imagination, a development which still gives him the heebie-jeebies. The Web site spawned a book, coincidentally also titled The Old New Thing (Addison Wesley 2007). He occasionally appears on the Windows Dev Docs Twitter account to tell stories which convey no useful information.

6 comments

Discussion is closed. Login to edit/delete existing comments.

Adam Jensen June 11, 2025

Why do I need to set some registry value to enable long path support?
- Danielix Klimax June 11, 2025
  
  You’re on Old New Things, I’d think it is obvious…
  
  Hint: What happens to old program getting long path…
  - Michael Taylor June 12, 2025
    
    >> Old applications do not have a longPathAware manifest so nothing happens.
    
    That's funny. Clearly you weren't writing code back in the days when this was first introduced. The 2 most common results of enabling LFN support on an app that didn't support them was: buffer overflow and inaccessible files, in my experience.
    
    Buffer overflow was the worse and a security risk. This was back before security was really at the top of everyone's list. The most common code used to get a filename allocated a character array of MAXPATH size. This was more efficient and easier to write then dynamically allocating...
    Read more
    >> Old applications do not have a longPathAware manifest so nothing happens.
    
    That’s funny. Clearly you weren’t writing code back in the days when this was first introduced. The 2 most common results of enabling LFN support on an app that didn’t support them was: buffer overflow and inaccessible files, in my experience.
    
    Buffer overflow was the worse and a security risk. This was back before security was really at the top of everyone’s list. The most common code used to get a filename allocated a character array of MAXPATH size. This was more efficient and easier to write then dynamically allocating memory. A program might then call an API that returned a filename. Depending on the API it might accept the buffer and length to write the filename into, it might preallocate the buffer and ask that you free it, or it might return a pre-existing buffer that you are expected to copy the value out of. In this latter case code that wasn’t LFN aware assumed a MAXPATH size, which they already had a buffer for, and would simply string copy to their buffer. The old string copy (pre-secure) would stomp over the buffer plus whatever memory was after it. In the best case it stomped read only memory and you got an access violation. More likely, since it was on the stack, it was stack corruption but you were unlikely to see the error because of how the stack is managed. In the worst case though you could stomp over other variables and corrupt the system. This is why malicious code was so easy to inject into programs back then.
    
    The inaccessible file case meant a user/program could create a file path that was too long to be recognized. Hence the user couldn’t access the file/path in the program even though it was accessible in Windows. This has actually been a problem up to even a handful of years ago. There were some dev tools (can’t remember which ones) that couldn’t handle LFN and this has been supported for decades now. It didn’t help at the time that MS started recommending LFNs for apps by suggesting file paths like `C:\Documents and Settings\\\` as defaults to avoid conflicts with others apps. I suspect that is one of the reasons later OS versions simplified it to `C:\users`. Easier to type, makes more sense and shorter…
    
    Read less
  - ‪ ‪ June 12, 2025
    
    Old applications do not have a longPathAware manifest so nothing happens.
- Georg Rottensteiner June 11, 2025
  
  Only if you want to use long paths without the \\?\ prefix. With the prefix you don’t need to do that.
  In my code base I modify all file/path accesses to use the \\?\ prefix internally.
  - Vladimir Vissoultchev June 12, 2025
    
    Extremely dangerous as users might then produce with your program some “undeletable” files on their Desktop.