It seems FlushFileBuffers() doesn’t set end-of-file (and therefore can lead to corrupted files)

  c++, winapi, windows

Consider following sequence of calls captured with process monitor:

image

Here is what happens here:

  1. file is opened
  2. 15-bytes file write
  3. FlushFileBuffers() call is made
  4. … which leads to 4kb file write issued by OS
  5. file handle is closed via Close()
  6. … which results in SetEndOfFileInformation() call which sets end-of-file at 15

This leads me to conclude that pulling network cable (or crashing server, etc) after #4 (but before #6) will lead to corrupted file on the server. And therefore successful FlushFileBuffers() call doesn’t guarantee file is not corrupted in case of outages.

Which in turn means Close() can always fail (even after successful FlushFileBuffers()) and therefore can’t be tucked away in some destructor. It has always to be an explicit call (unless you already rolling back/unwinding due to some other error).

Am I correct? And if not — why?

Source: Windows Questions

LEAVE A COMMENT