msync equivalent in Windows

Question

what is the equivalent of msync [unix sys call] in windows? I am looking for MSDN api in c,C++ space. More info on msync can be found at http://opengroup.org/onlinepubs/007908799/xsh/msync.html

Answer 1

FlushViewOfFile

Checkout the Python 2.6 mmapmodule.c for an example of FlushViewOfFile and msync in use:

/*
 /  Author: Sam Rushing <[email protected]>
 /  Hacked for Unix by AMK
 /  $Id: mmapmodule.c 65859 2008-08-19 17:47:13Z thomas.heller $

 / Modified to support mmap with offset - to map a 'window' of a file
 /   Author:  Yotam Medini  [email protected]
 /
 / mmapmodule.cpp -- map a view of a file into memory
 /
 / todo: need permission flags, perhaps a 'chsize' analog
 /   not all functions check range yet!!!
 /
 /
 / This version of mmapmodule.c has been changed significantly
 / from the original mmapfile.c on which it was based.
 / The original version of mmapfile is maintained by Sam at
 / ftp://squirl.nightmare.com/pub/python/python-ext.
*/

static PyObject *
mmap_flush_method(mmap_object *self, PyObject *args)
{
    Py_ssize_t offset = 0;
    Py_ssize_t size = self->size;
    CHECK_VALID(NULL);
    if (!PyArg_ParseTuple(args, "|nn:flush", &offset, &size))
     return NULL;
    if ((size_t)(offset + size) > self->size) {
     PyErr_SetString(PyExc_ValueError, "flush values out of range");
     return NULL;
    }
#ifdef MS_WINDOWS
    return PyInt_FromLong((long) FlushViewOfFile(self->data+offset, size));
#elif defined(UNIX)
    /* XXX semantics of return value? */
    /* XXX flags for msync? */
    if (-1 == msync(self->data + offset, size, MS_SYNC)) {
     PyErr_SetFromErrno(mmap_module_error);
     return NULL;
    }
    return PyInt_FromLong(0);
#else
    PyErr_SetString(PyExc_ValueError, "flush not supported on this system");
    return NULL;
#endif
}

UPDATE: I don't think you are going to find complete parity in the win32 mapped file APIs. The FlushViewOfFile API doesn't have a synchronous flavor (probably because of the possible impact of the cache manager). If precise control over when data is written to disk is required perhaps you can use the FILE_FLAG_NO_BUFFERING and FILE_FLAG_WRITE_THROUGH flags with the CreateFile API when you create the handle to your mapped file?

Answer 2

Hi Mark, thanks for the quick reply. I am aware of mysnc and FlushViewOfFile usage. In the code pasted,we can see depending on the OS, we call the corresponding sys call- msync [in unix] and flushviewofFile [in windows]. What i am looking for is a mechanism wherein we can ensure that calling FlushViewofFile commits the changes to the harddisk before returning:

From msdn docs of FlushViewofFile:

"Flushing a range of a mapped view initiates writing of dirty pages within that range to the disk. Dirty pages are those whose contents have changed since the file view was mapped. 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."

FlushFileBuffers() can be used for this purpose but this is valid only on a file handle. What i have is a memory mapped region which needs to be commited to the disk.For this i initially cal FlushViewoffile passing the base address and number of bytes to flush.

msync achieves this in a single call- flushing the data-file contents/byte buffers and commiting to the hard disk. i wanted a equivalent functionality in windows.

Answer 3

I suspect FlushViewOfFile actually is the right thing. When I read the man page for msync, I would not assume that it is actually flushing the disk cache (the cache in the disk unit, as opposed to the system cache in main memory).

FlushViewOfFile won't return until the disk stack has completed the writes; like the msync documentation, it says nothing about what happens in the disk cache. We should probably take a look at making that more clear in the documentation.