Boost logo

Boost :

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.

Boost list run by bdawes at, gregod at, cpdaniel at, john at