Let’s say you are performing a write to a file using Memroy Mapped I/O, that is, using CreateFileMapping and MapViewOfFile. You might be surprised to see that the last modified timestamp on the file did not change even though you did an actual write on the file, then unmapped the view, you closed all the handles, and verified that the file has actually been modified. Yet still, its last modified time stamp remains the same. So why is that?
First, you need to close the file handle after unmapping the view. The order here is important. Because the Memory Manager only udpates the timestamps when the handle is closed. So you need to make sure that you have completed all your writes through your mapped view and then close the handle, Then the timestamp would be updated, — or… more accurately — may get updated.
That is right, even with closing the handles in the proper order, you can’t always bet that the time will be modified correclty. The behavior in this scenario is still unpredictable. The reason? The Memory Manager writes data at a time that it chooses, the process itself does not control when that happens. So when you close the handle, the data might still be living in cache, and the filesystem still doesn’t see it yet. So it still thinks that no writes or modifications have been been performed yet, and as a consequence it woundn’t update the timestamp. Another possibility is that if there was another process before yours that cached or mapped the file first, then the Memory Manager will use its handle to do all the writes, and will only update the timestamp when that handle is closed.
So if you really want to make sure that the last modified timestamp is updated during a mapped file I/O, then your best bet would be to call SetFileToCurrentTime to set the last modified time explicitely. Or you can do one write through the filesystem after you are done with your modification, which will update the last modified time.