After reviewing this, I think I spoke too soon. The above restrictions are consistent with Posix. I had thought that mmap would allow mapping beyond the file current size, but it seems not. One should use ftruncate to set the size before mmap instead.

Since ftruncate isn't portable, it seems something like this (warning: untested) would be appropriate for boost::filesystem (perhaps taking a path object as an argument instead of a string - and shouldn't the Boost IO library do the same?) #ifdef _WIN32 #include <io.h> #else #include <unistd.h> #endif bool create_file(const std::string& path,std::size_t size) { #ifdef _WIN32 int fh=::_open(path.c_str(),_O_CREAT|_O_SHORT_LIVED); if (fh == -1) return false; if (::_chsize(fh,size) == -1) return false; return ::_close(fh) != -1; #else return ::truncate(path.c_str(),size) != -1; #endif } I don't see how, in Windows, to atomically keep the file open before it's mmapped, because chsize takes an int fh and the (equivalent of) mmap takes a HANDLE (maybe there is some Win32 call to get the HANDLE from the int fh?). The abstraction/interface that seems to be missing here is a low level (operating system level) file descriptor that can be passed to platform specific functions like ftruncate or _chsize, which weren't anticipated and wrapped by the higher-level libraries. I'd also like to see a constructor for mapped_file that creates a new file of exactly the required size (this might be a reasonable request for mapped_file_sink as well). It might also be nice to be able to set MAP_SHARED vs MAP_PRIVATE, or to be allowed to atomically deactivate an existing mapped_file (substituting a new backing file), guaranteeing the same address space (this is, I think, feasible if you do no allocation between munmap and mmap, and you can always detect failure by setting MAP_FIXED). I guess there's enough work left to be done for a "proper" Windows/POSIX mmap wrapper that the IO library shouldn't attempt to promote it yet.