This is one of my posts of “study the mistakes of others, so you can learn from them and not repeat them directly or indirectly”.

This is common to see, at least for me

The directory name y:\backup-2012-09-01-2230\Applications\Adobe Acrobat 9 Pro\Adobe Acrobat Pro.app\Contents\Plug-ins\PaperCapture.acroplugin\Contents\Frameworks\OCRLibrary.framework\Versions\A\Frameworks\iDRS.framework\Versions\A\Resources\Asian.framework\Versions\A\.AppleDouble is too long.

(ignore the fact I’m cataloging Mac apps on a Windows share).

The 260 character limit is so deeply embedded in the Windows system that it’s been almost impossible for Microsoft to eradicate it; it persists even into theoretically new frameworks like .NET (mainly because .NET isn’t actually a completely new system, it’s in many cases a thin shim on top of the older Win32 libraries). While there are APIs that let you access paths up to 32767 characters long, there’s enough bits in the system that use the older MAX_PATH limit that you really can’t do anything about it. So while you can use Windows NT-style paths in many cases (paths prefixed with \\?) in your own code, some core APIs in Windows use the old functions (like LoadLibrary, for example).

Note that you can use \\? paths with cmd.exe, BUT these must be drive letter paths, UNC paths don’t work (don’t know why, maybe one needs to use the NT file namespace or volume GUID path?), and it’s useless, because the resultant path is still subject to MAX_PATH limitations. You also can’t set the current working directory to a UNC path (unless you employ a registry hack, see Microsoft KB 156276).

There are a few workarounds I’ve used in the past:

• using working directories
• use of subst and/or pushd (auto-subst, don’t forget the matching popd)
• hard links, junctions, and symbolic links (although these modify the filesystem)

All of these create new virtual hierarchies so that you can read a deeply nested file without needing a path longer than MAX_PATH; the first two can at best double the length, though.

There are some wacky things people have done in code.

Starting in Windows Vista, the shell starts shrinking individual elements in the path until the whole thing fits within MAX_PATH. This is why you can browse a really deep hierarchy in Explorer.exe, and usually copy it or delete it. This, of course, requires that NT short name creation is not disabled.

Of course, the real answer is “stop using Windows, and just use Unix (Linux or Mac OS X)”, but there’s still a lot of programs that run on Windows and not Unix…

Reference

• Naming Files, Paths, and Namespaces (Windows) on msdn.com
• cmd – Command Shell | SS64.com
• How to deal with “CMD does not support UNC paths as current directories“
• pushd
• Long Paths in .NET, Part 1 of 3 [Kim Hamilton] (and part 2, and part 3)
• Sometimes what a person really wants is a LACK of size (Microsoft Shell auto-shrinking)
• shellrevealed.com archive
• StackOverflow article