Subject: Re: [boost] [build] File / path lengths difficult to manage on Windows
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-11-13 21:13:37
On 14/11/2013 14:31, Quoth Ben Craig:
> I think this is being unrealistic. If we take this approach, then you
> should request every Win32 program that uses fopen, iostreams, or
> CreateFile without the magic marker to change their program to use a
> non-portable API. This includes programs like cmd.exe, explorer,
> bjam, 7zip, and countless others.
Did you mean to quote someone else? Because I was agreeing with you.
> I wish that "normal" Windows APIs permitted a higher maximum path
> length, but they don't. Reasonable Windows support means
> acknowledging this limitation.
It's unfortunately a wart of its DOS outgrowth. Back in the days of 8.3
filename limits a total path length of 260 was ample, and most of the
early DOS APIs were based around local stack buffers of [MAX_PATH].
This has ended up getting carried forward via backwards-compatibility,
because the APIs don't provide any way to accept the buffer size
explicitly and it can't be increased arbitrarily without crashing older
programs.