In the Windows API the maximum length for a path is 260 characters.

Slightly edited for length, but that comes from MSDN. Yes, it’s 2014, we’ve dealt with the 8.3 filename limit, found the Higgs Boson, landed a fridge on a comet, but the Windows API still doesn’t play well 260 character length file paths. That’s unfortunate.

The migration that I’ve been working on involves a network file share. Somehow (and just how is a mystery), some of the file paths involved are longer than 260 characters. Of course, they’re had to spot in this large, complex folder structure, but when I wrote code to enumerate all files, well, I started getting to get PathTooLongExceptions.

Looking at MSDN it suggests using the

\\?\

prefix to the path, and that should allow paths 32,000 characters long. Great! That should be easy then, right?

Well, no. This is blogged about on MSDN too (albeit a bit old) and this line matches my own experience of trying this.

There are several reasons we were reluctant to add long paths in the past, and why we’re still careful about it, related to security, inconsistent support in the Windows APIs of the \\?\ syntax, and app compatibility

“Inconsistent support”? Damn right; that was what I found when I tried to use it. They go on to say…

A possible workaround is P/Invoking to the Windows APIs and using the \\?\ prefix, but it would be a huge amount of code to duplicate the functionality in System.IO.

This is where things get interesting. It might be a lot of work, but I think it says something that this is exactly what a number of projects have tried to do. I only looked at two:

• Delimon.Win32.IO Library
• AlphaFS on Codeplex

Both took the approach of trying to duplicate the classes and methods of the System.IO namespace, which is, apparently, too much effort for Microsoft. Hmm.

However, it does make it very easy to add them. Reference the assemblies, and swap your using System.IO for the appropriate alternative. I did find a few small differences in the APIs – they weren’t perfect duplicates – but those were minor.

Did they work, though? In short – not entirely, no. They weren’t entirely reliable.

In the end the safest and quickest approach we found was to have someone manually update the folder structure on the shared drive. That’s a bit embarrassing, and at some point Microsoft will have to accept the need to do better – finally.

EDIT: See also Filesystem Paths: How Long is Too Long?, though I respectfully disagree with Jeff Atwood’s comment “I think 260 characters of path is more than enough rope to hang ourselves with.” He is right about that, but only as far as it goes. These paths do exist, do get created, and you can try and re-educate about a billion people – or you could make the API work.