Consider following sequence of calls captured with process monitor:
Here is what happens here:
- file is opened
- 15-bytes file write
FlushFileBuffers()call is made
- … which leads to 4kb file write issued by OS
- file handle is closed via
- … 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