如何编写文件然后将其读回以验证其内容，确保您获得磁盘上的内容而不是缓存

Question

I'm using native/C++/Win32/MFC code on Windows to save a document file via MFC serialization. I've inserted my own CFile-derived class in the writing process giving me access to the data as its being written. This allows me to compute a checksum (or hash, etc) on the data as its going out to the file.

After the files has saved, I'd like to allow the option of verifying the file. The idea would be to re-open the file and read through it verifying the checksum/hash/etc.

I'm wondering, though, if its possible that after having just written the file, the OS could be giving me unwritten data when I read the file back right away. In this case, the test doesn't really tell me that the file looks good on the disk.

Is my concern valid? If so, is there any way to avoid this issue?

Answer 1

If you are using CFile , you can call CFile::Flush to ensure everything is written to disk. According to the documenatation

virtual void Flush( );

Forces any data remaining in the file buffer to be written to the file

Answer 2

If you really want to do this then you can avoid disk caching and buffering by specifying FILE_FLAG_NO_BUFFERING and/or FILE_FLAG_WRITE_THROUGH when opening the file. Beware that using these options will complicate things.

The file or device is being opened with no system caching for data reads and writes. This flag does not affect hard disk caching or memory mapped files. There are strict requirements for successfully working with files opened with CreateFile using the FILE_FLAG_NO_BUFFERING flag, for details see File Buffering .

A simpler alternative is to call FlushFileBuffers just before you close the file handle.

Answer 3

I do not know the answer to this question. However, I do know where to look.

SQLite guarantees that data is safely written to disk, no matter what happens - even a power failure. They must be doing what you need, their code is open source and beautifully commented.

All changes within a single transaction in SQLite either occur completely or not at all, even if the act of writing the change out to the disk is interrupted by

a program crash,

an operating system crash,

or a power failure.

The claim of the previous paragraph is extensively checked in the SQLite regression test suite using a special test harness that simulates the effects on a database file of operating system crashes and power failures.

http://sqlite.org/transactional.html