Re: [boost] [build] File / path lengths difficult to manage on Windows

Subject: Re: [boost] [build] File / path lengths difficult to manage on Windows
From: Ben Craig (ben.craig_at_[hidden])
Date: 2013-11-13 20:31:56

>From: Gavin Lambert 
>On 14/11/2013 06:31, Quoth Niall Douglas:
>> I would report this as a bug to 7zip. The MAX_PATH limit is purely
>> for backwards compatibility only, and every Win32 API can easily take
>> 32k paths by prepending a magic marker.
>
>There are some downsides to this, such as losing current directories and 
>relative paths.  (Also, there are many applications that still only use 
>the ANSI APIs, which do not accept the magic marker.)
>
>Having said that, 7zip is the sort of program that shouldn't have 
>trouble with any of that.  (But it still might make building or browsing 
>the documentation harder later on.)

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.

I wish that "normal" Windows APIs permitted a higher maximum path length, but they don't.  Reasonable Windows support means acknowledging this limitation.