[boost] [filesystem v3] [iostreams] [interprocess] no windows access to memory mapped file

Subject: [boost] [filesystem v3] [iostreams] [interprocess] no windows access to memory mapped file
From: Jeff Flinn (TriumphSprint2000_at_[hidden])
Date: 2011-02-25 09:31:51

Filesystem V3 does a great job of handling unicode/utf8 paths in a 
windows/posix independent manner.

boost::interprocess::file_mapping's constructor takes a raw const char* 
and explicitly calls CreateFileA to get a handle to a memory mapped file 
disallowing access to paths with non-ascii characters.

boost::iostreams::mapped_file has a 7 month old ticket #4485 outlining 
the problems using it with filesystem V3. There is some path width 
switching logic that dispatches to CreateFileA or CreateFileW when the 
mapped_file is constructed with a filesystem V2 wpath. I tried faking 
things out by creating a wpath class in the filesystem namespace, but 
gave up and created a mapped file class for windows that uses 
filesystem::path and CreateFileW.

I posted the issue with interprocess and Ion was of the opinion that 
this shorcoming needs to be addressed. I'm not sure if Steven is 
maintaining iostreams, or if he has given thought to how to address the 
iostreams implementation. My opinion is that boost libraries using paths 
in their interfaces should be using filesystem v3 paths. Beman, I think, 
suggested in the recent utf8 thread that boost libraries should use the 
wide version of the windows api passing path.wstring().c_str() where 
appropriate.

Do others have thoughts on this issue? Are the windows wide api usage 
part of boost guidelines? Should they be?

Thanks, Jeff