On 5/02/2015 14:36, Niall Douglas wrote:
On 5 Feb 2015 at 10:57, Gavin Lambert wrote:
Windows in general does not react well to paths exceeding this limit anywhere. While yes, there are ways to bypass the limit, there are many restrictions on this functionality and most applications don't use those alternatives and so will choke if they happen to come across such a path. It's usually limited to very specialised scenarios (eg. backup software).
You'd be surprised at how wrong you are for this with most command line apps, all of mingw and in fact the Windows Explorer as of Windows 8.1. I have a Jenkins install which goes _way_ over the 260 char limit on Windows, and do you know what the *only* build tool to always puke on that is?
Anything that uses relative paths is relatively immune (pun somewhat intended), provided they're only accessing children or at least near neighbours of the deep path. This actually allows a lot of software to work by coincidence, where the intent of the author was to access a file in the application directory but due to lazy coding the app used a relative path under the assumption that the working dir was the application dir. (An assumption that *usually* holds for GUI apps, but fails often enough to get you into trouble -- and *rarely* holds for command line apps, unless they're not in the PATH.)
Some time ago I raised with Microsoft the urgent need to bump MAX_PATH in Microsoft libc to something sane like 1024, or god forbid, the actual 32767 that the NT kernel supports. The answer was a definite no as it would be a nightmare of compliance testing with never ending corner case bugs, and this I could believe when you examine the MSVCRT source code. Perhaps their brand new rewritten MSVCRT in VS2015 has significantly improved here.
That is a chicken-and-egg problem, but it's a different one than what I was thinking of. (Note that MAX_PATH is defined in the Win32 API, not the CRT.) The problem there is that there are too many existing APIs that write into a buffer without being given a buffer size explicitly (caller is expected to make it at least MAX_PATH chars long, function guarantees to not write more than MAX_PATH chars). This is obviously a problem if the two sides do not agree on the value of MAX_PATH, which would be the case for old application vs. new Windows version if they changed it. Similarly there is a lot of existing code that assumes that even in the APIs that do accept a buffer size, when using MAX_PATH as the buffer size the API "cannot" fail with a buffer size error. (Whether this is good code or not is out of scope -- there's a lot of it in the wild.) These would also do peculiar things if this assumption were violated. Making the C/C++ runtime support extended paths would definitely be a step forward, but it's still very common to completely sidestep the CRT and go straight to the WinAPI, because it has more features.