id	summary	reporter	owner	description	type	status	milestone	component	version	severity	resolution	keywords	cc
7793	Not needed code for mapped files in windows	lodos@…	Ion Gaztañaga	"The exchange below took place on the boost developer list, it describes the request. Thank you.

> > > 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?
> >

> > Interprocess tries to simulate as much as possible POSIX guarantees.
> > truncate() POSIX system call guarantees that ""If the file is
> extended,
> > the extended area appears as if it were zero-filled"". In windows,
> > SetFileValidData/SetEndOfFile does not zero-fill the extended size so
> > Interprocess needs to write it.

> 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?

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.
"	Tasks	new	To Be Determined	interprocess	Boost 1.52.0	Optimization		mapped file grow