https://svn.boost.org/trac10/ticket/7793 <p> The exchange below took place on the boost developer list, it describes the request. Thank you. </p> <blockquote class="citation"> <blockquote class="citation"> <blockquote class="citation"> <p> When you grow a managed mapped file, the current implementation fills all the new space with zeroes. This is less efficient than just resizing the file. The comments in the code implies there is a reason, so what is it? </p> </blockquote> </blockquote> </blockquote> <blockquote class="citation"> <blockquote class="citation"> <p> Interprocess tries to simulate as much as possible POSIX guarantees. truncate() POSIX system call guarantees that "If the file is </p> </blockquote> <p> extended, </p> <blockquote class="citation"> <p> the extended area appears as if it were zero-filled". In windows, <a class="missing wiki">SetFileValidData/SetEndOfFile</a> does not zero-fill the extended size so Interprocess needs to write it. </p> </blockquote> </blockquote> <blockquote class="citation"> <p> Given that the mapped file content is not part of the library interface, and the only expected user of the mapped file is the library itself, why waste time in Windows? Seems to me that a requirement that files should be identical is too strong, as long as they work and perhaps don't affect platform portability. File portability between platforms should be warranted? What about platforms with different endianness? </p> </blockquote> <p> I need to investigate it, but I tried to support similar behaviour for internal file-handling functions. I'll need to think it again. Please fill a ticket so this doesn't get lost when reviewing pending issues. </p> en-us /htdocs/site/boost.png https://svn.boost.org/trac10/ticket/7793 Trac 1.4.3