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

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 
too.

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 
C++.

Niall
-- 
ned Productions Limited Consulting
http://www.nedproductions.biz/ 
http://ie.linkedin.com/in/nialldouglas/