The Long Path for the BCL Team

BCL Team Blog - Long Paths in .NET, Part 3 of 3 Redux [Kim Hamilton]

“My original part 3 blog caused confusion, mostly because it didn’t tie together loose ends and explain that an immediate .NET “solution” is at best partial. To minimize confusion and answer questions in the comments, I decided to do a complete overhaul and link to the original (here).

Win32 file-naming conventions include the MAX_PATH (260 character) restriction. A subset of Win32 APIs allow you to work around the MAX_PATH restriction by adding the \\?\ prefix.

…

Proposed “Solution” (Best attempt for now)

We won’t be able to provide seamless long path support throughout .NET until something is done on the Win32 side to broaden support of long paths throughout their APIs.

As a mitigation to at least provide parity with Win32, we propose to allow use of the \\?\ prefix (described in #2 above) to avoid the MAX_PATH limitation. The caller must explicitly use this prefix, at best aided with a helper API as follows:

…”

I feel for the BCL team. They are caught between a rock and a hard place. Caught between us, developers, and the underlying OS. And for something as baked into Windows as MAX_PATH, there’s not all that much they can really do. But the good news is that they ARE at least doing what they can. They acknowledge the issue and are actively doing what they can to help. You go BCL team!

That said, now it’s time that the OS, Win32 (Win64?) API, and UI move into the future and give us the “hard right” solution.

Long paths, paths > MAX_PATH, are one of the bains of my existence at work. It’s a long story that I’ve mentioned many times before, but let’s just say I feel MAX_PATH needs to go. That the OS, utilities, UI, etc need to support Unicode path lengths. That “//?"/” helps, but without Explorer, command line support (without going to the Posix, Windows Services for Unix, utilities), etc support anything we do is only half the solution. The fact that I’m considering writing my own “Windows Explorer” (or “File Manager” ;) just so I can give my users a file management UI that supports long paths is… well… insane.

With the explosion of HD space, MAX_PATH has to go. When my wife and son, as normal users, are banging their heads against it, it’s a sign.

Yes, I know, that’s SO much easier said than done. I can’t even imagine the impact, work and testing required to resolve this, nor the massive impact on third parties, but still it’s time for the hard right answer over the easy wrong one. Want a “big bang” “huge increase” side of the box figure for Windows 7? How about “You can now create paths 32,000 characters long! That’s an 800% increase!” (assuming my math is correct ;)

(Of course even though my solution’s support “long paths”, some cap out at 2048 characters… So maybe I should shut up and be careful what I ask for! LOL ;)

(via Alvin Ashcraft’s Morning Dew - Dew Drop - July 8, 2008)