How to write a file, then read it to check its contents, ensuring that you get what is on disk and not cache

Question

I am using native / C ++ / Win32 / MFC code for Windows to save a document file using MFC serialization. I inserted my own CFile-derived class into the writing process, giving me access to the data as it is written. This allows me to calculate the checksum (or hash, etc.) from data like its output to a file.

After saving the files, I would like to allow the ability to check the file. The idea was to reopen the file and read it by checking the checksum / hash / etc.

I am interested, however, if it is possible that after he just wrote the file, the OS can give me unwritten data when I read the file right away. In this case, the test does not actually tell me that the file looks good on disk.

Is my concern valid? If so, is there a way to avoid this problem?

Answer 1

If you use CFile , you can call CFile :: Flush to make sure everything is written to disk. According to the documentation

virtual void Flush( ); 

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

Answer 2

If you really want to do this, you can avoid caching and buffering the drive by specifying FILE_FLAG_NO_BUFFERING and / or FILE_FLAG_WRITE_THROUGH when opening the file. Remember that using these options will complicate the situation.

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

A simpler alternative is to call FlushFileBuffers just before closing the file descriptor.

Answer 3

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

SQLite ensures that data is safely written to disk, no matter what happens - even a power failure. They should do what you need, their code is open source and beautifully commented on.

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

program crash

operating system crash

or power failure.

The requirement of the preceding paragraph is tested in detail in SQLite by a set of regression tests using a special test harness that simulates the effect on the database file of failures and operating system power failure.

http://sqlite.org/transactional.html