Boost logo

Boost :

Subject: Re: [boost] [filesystem] temp_directory_path() behavior on Windows
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-02-04 20:36:13

On 5 Feb 2015 at 10:57, Gavin Lambert wrote:

> > That's a reasonable point. Apart from its hardcoded 260 char limit.
> 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?

Answer: Boost.Build. Everything else, from git to MSVC to Python and
Java, works just fine [1]. I can also confirm that Notepad++ is happy

There are some interesting exceptions though. The biggest is that
rmdir /s fails and also refuses to accept the \?\ prefix, as does
attempting to delete the whole tree from Explorer - though deleting
individual files deep into the hierarchy are fine. You can workaround
the rmdir /s limitation using robocopy oddly enough which is happy
with long paths, but it is frustrating that the tooling falls short
on rm -rf directory trees as it's common enough in CI usage.

Another unfortunate issue is that all .NET code is 260 limited. A
real missed opportunity there.

[1]: When called with the current working directory set inside the
deep path. Python's support is incomplete - it auto-prefixes paths
when they are too long, but does not implement cwd or relative path
substitution with extended paths. The debate on whether to finish
this support or push the problem onto the user continues, but if your
python program only works with absolute paths and uses os.path for
path manipulations, extended paths work.

> Perhaps this is a chicken-and-egg problem (if it were easier for apps to
> deal with longer paths, maybe they'd do it, and then eventually
> everybody would start doing it -- suggesting that a useful goal of a
> library would be to make this easy) though.

There is an interesting story on this :)

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.

So yes, it is a chicken and egg problem. If the standard library
shipped with C++ always uses extended paths, that is an enormous leap
forward creating pressure on Microsoft to fix this problem. A lot of
other languages like Python and Java already use extended paths, even
with reduced functionality as soon as the path exceeds 259. So should


ned Productions Limited Consulting

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