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/