10 out of 12 rated this helpful - Rate this topic

FlushFileBuffers function

Applies to: desktop apps | Metro style apps

Flushes the buffers of a specified file and causes all buffered data to be written to a file.

Syntax

BOOL WINAPI FlushFileBuffers(
  __in  HANDLE hFile
);

Parameters

hFile [in]

A handle to the open file.

The file handle must have the GENERIC_WRITE access right. For more information, see File Security and Access Rights.

If hFile is a handle to a communications device, the function only flushes the transmit buffer.

If hFile is a handle to the server end of a named pipe, the function does not return until the client has read all buffered data from the pipe.

Return value

If the function succeeds, the return value is nonzero.

If the function fails, the return value is zero. To get extended error information, call GetLastError.

The function fails if hFile is a handle to the console output. That is because the console output is not buffered. The function returns FALSE, and GetLastError returns ERROR_INVALID_HANDLE.

Remarks

Typically the WriteFile and WriteFileEx functions write data to an internal buffer that the operating system writes to a disk or communication pipe on a regular basis. The FlushFileBuffers function writes all the buffered information for a specified file to the device or pipe.

Due to disk caching interactions within the system, the FlushFileBuffers function can be inefficient when used after every write to a disk drive device when many writes are being performed separately. If an application is performing multiple writes to disk and also needs to ensure critical data is written to persistent media, the application should use unbuffered I/O instead of frequently calling FlushFileBuffers. To open a file for unbuffered I/O, call the CreateFile function with the FILE_FLAG_NO_BUFFERING and FILE_FLAG_WRITE_THROUGH flags. This prevents the file contents from being cached and flushes the metadata to disk with each write. For more information, see CreateFile.

To flush all open files on a volume, call FlushFileBuffers with a handle to the volume. The caller must have administrative privileges. For more information, see Running with Special Privileges.

When opening a volume with CreateFile, the lpFileName string should be the following form: \\.\x: or \\?\Volume{GUID}. Do not use a trailing backslash in the volume name, because that indicates the root directory of a drive.

Examples

For an example, see Multithreaded Pipe Server.

Requirements

Minimum supported client

Windows XP

Minimum supported server

Windows Server 2003

Header

FileAPI.h (include Windows.h);
WinBase.h on Windows Server 2008 R2, Windows 7, Windows Server 2008, Windows Vista, Windows Server 2003, and Windows XP (include Windows.h)

Library

Kernel32.lib

DLL

Kernel32.dll

See also

CreateFile
File Management Functions
WriteFile
WriteFileEx

 

 

Send comments about this topic to Microsoft

Build date: 4/17/2012

Did you find this helpful?
(1500 characters remaining)
Community Content Add
Annotations FAQ
Write fails even with synchronous function calls
The same thing happened on Windows 7 when using synchronous write operations:
A large series of fwrite() calls is interrupted by jumping backwards some kbytes using fseek(), re-writing a few bytes using fwrite(), returning to previous position using fseek(), then continue with multiple fwrite() calls.
The single writing call at the outlying backward position is dropped. The previous contents of this region is retained. Maybe the write is treated like an asynchronous write since it affects a different file sector. All function calls return success.
The problem does not occur when running on Win XP.
FlushFileBuffers and writeFile and iocp
The same thing happened to me on 2008 R2.  No problems on any 2003 servers.  Data drop outs were aligned to the disk cluster boundries.  Spent 6 days figuring this out.
WriteFile while FlushFileBuffers running can corrupt your file
Windows 7 occasionally drops an async WriteFile that is issued in one thread while FlushFileBuffers is running in another. WriteFile, GetOverlappedResult(,,,TRUE), and FlushFileBuffers all return success. The region of the file corresponding to the WriteFile however is allocated but unwritten. The region contains whatever happens to be on the disk - often portions of deleted files or FS metadata.