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

Subject: Re: [boost] [build] File / path lengths difficult to manage on Windows
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2013-11-15 16:34:25

On 15 Nov 2013 at 13:52, Gavin Lambert wrote:

> On 15/11/2013 08:52, Quoth Niall Douglas:
> > I've bumped the notion of raising that limit to our friends in
> > Microsoft. Who knows, it may be possible for Windows 8.2!
> 
> As I previously mentioned, I don't think it's something they can do on a 
> version boundary, only on an ABI boundary (eg. 32-bit vs. 64-bit, or by 
> introducing new APIs).
> 
> There's just too much existing (and will not be recompiled) code that 
> has stack based char[MAX_PATH] buffers.
> 
> They can't even do the manifest-version-based shimming that they're 
> doing for some other things, as that's defined at the process level -- 
> just because an application claims that it knows about a larger MAX_PATH 
> doesn't mean that all the DLLs that it uses does.

I wouldn't be proposing that MAX_PATH should be changed for any code 
not being compiled for the latest toolset where MAX_PATH was 
extended. So, if you're linking to MSVCRT13.DLL then you get 
MAX_PATH=1024, while any previous MSVCRT gets MAX_PATH=260.

What about mixed MSVCRT apps? Well, already those aren't reliable and 
you shouldn't do them :) But it still should usually work as usually 
application code is compiled with a newer toolset than library code, 
and therefore you're passing in a larger buffer which may cause 
library code to puke on the longer path, but not corrupt memory. A 
lot of time library code simply passes through externally supplied 
buffers anyway, and therefore doesn't care.

> (Not that I wouldn't love them to try, I just wouldn't hold out much 
> hope for it.)

I got a response - it is thought highly unlikely to be successful. I 
guess you'd need to make a convincing business case, and I agree 
given Windows' size in the market they don't have to bother adapting 
to others i.e. if you're porting to Windows, you accept the 260 char 
path limit as part of the porting effort and all the code refactoring 
therefore needed.

BTW, my current side project of implementing a standard transactional 
graph database gets rid of the path length limitation on Windows. One 
of its interfaces is a POSIX-like file system interface, and by 
POSIX-like I mean it looks just like a POSIX file system except it 
has more reserved characters for working with things like multiple 
file versions, creating directories which are really live searches on 
the graph store, being able to transact update many files atomically 
or not at all etc. My idea is that (eventually) you could mount this 
graph store as a fuse filesystem and work with it as if it were a 
real file system.

Niall

-- 
Currently unemployed and looking for work.
Work Portfolio: http://careers.stackoverflow.com/nialldouglas/