|
Boost : |
Subject: Re: [boost] [build] File / path lengths difficult to manage on Windows
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2013-11-17 17:25:05
On 16/11/2013 10:34, Quoth Niall Douglas:
> 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.
That's not where MAX_PATH comes from though. It's in the Windows SDK,
not the C Runtime. There's plenty of code that calls the WinAPI
directly, and that's where the value of MAX_PATH matters.
> 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.
Sounds a little like the database-based filesystem MS were planning to
replace everything with in Vista, but eventually abandoned. (WinFS, I
think it might have been called..?)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk