Re: [boost] [filesystem] temp_directory_path() behavior on Windows

Subject: Re: [boost] [filesystem] temp_directory_path() behavior on Windows
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2015-02-04 21:04:30

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.