"The FlushViewOfFile function does not flush the file metadata, and it does not wait to return until the changes are flushed from the underlying hardware disk cache and physically written to disk. To flush all the dirty pages plus the metadata for the file and ensure that they are physically written to disk, call FlushViewOfFile and then call the FlushFileBuffers function."
-- https://msdn.microsoft.com/en-us/library/windows/desktop/aa366563(v=vs.85).aspx
"The FlushViewOfFile function does not flush the file metadata, and it does not wait to return until the changes are flushed from the underlying hardware disk cache and physically written to disk. To flush all the dirty pages plus the metadata for the file and ensure that they are physically written to disk, call FlushViewOfFile and then call the FlushFileBuffers function." -- https://msdn.microsoft.com/en-us/library/windows/desktop/aa366563(v=vs.85).aspx
It appears, in
https://github.com/edsrzf/mmap-go/blob/master/mmap_windows.go#L75
that FlushViewOfFile() is used without FlushFileBuffers().
In contrast, the unix implementation (https://github.com/edsrzf/mmap-go/blob/master/mmap_unix.go#L38) calls msync(addr,len,MS_SYNC), which does guarantee after it returns that the data is then physically on the disk.
Reference: http://www.gnu.org/software/libc/manual/html_node/Memory_002dmapped-I_002fO.html