INFO: FILE_FLAG_WRITE_THROUGH and FILE_FLAG_NO_BUFFERING (99794)
The information in this article applies to:
- Microsoft Win32 Application Programming Interface (API), when used with:
- the operating system: Microsoft Windows NT 3.1
- the operating system: Microsoft Windows NT 3.5
- the operating system: Microsoft Windows NT 3.51
- the operating system: Microsoft Windows NT 4.0
- the operating system: Microsoft Windows 95
- the operating system: Microsoft Windows 98
- the operating system: Microsoft Windows 2000
- the operating system: Microsoft Windows Millennium Edition
- the operating system: Microsoft Windows XP
This article was previously published under Q99794 SUMMARY
The FILE_FLAG_WRITE_THROUGH flag for CreateFile() causes any writes made to
that handle to be written directly to the file without being buffered. The
data is cached (stored in the disk cache); however, it is still written
directly to the file. This method allows a read operation on that data to
satisfy the read request from cached data (if it's still there), rather
than having to do a file read to get the data. The write call doesn't
return until the data is written to the file. This applies to remote writes
as well--the network redirector passes the FILE_FLAG_WRITE_THROUGH flag to
the server so that the server knows not to satisfy the write request until
the data is written to the file.
The FILE_FLAG_NO_BUFFERING takes this concept one step further and
eliminates all read-ahead file buffering and disk caching as well, so that
all reads are guaranteed to come from the file and not from any system
buffer or disk cache. When using FILE_FLAG_NO_BUFFERING, disk reads and
writes must be done on sector boundaries, and buffer addresses must be
aligned on disk sector boundaries in memory.
These restrictions are necessary because the buffer that you pass to the
read or write API is used directly for I/O at the device level; at that
level, your buffer addresses and sector sizes must satisfy any processor
and media alignment restrictions of the hardware you are running on.
MORE INFORMATION
The Windows 95 CDFS (CD-ROM File System) does not support the
FILE_FLAG_NO_BUFFERING flag for CreateFile(). While a Windows 95 FSD, such
as VFAT, may implement it, FILE_FLAG_NO_BUFFERING is not a required flag
for file system drivers, and it is not supported by CDFS.
This code fragment demonstrates how to sector-align data in a buffer and
pass it to CreateFile():
char buf[2 * SECTOR_SIZE - 1], *p;
p = (char *) ((DWORD) (buf + SECTOR_SIZE - 1) & ~(SECTOR_SIZE - 1));
h = CreateFile(argv[1], GENERIC_READ | GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE, NULL, CREATE_ALWAYS,
FILE_ATTRIBUTE_NORMAL | FILE_FLAG_NO_BUFFERING, NULL);
WriteFile(h, p, SECTOR_SIZE, &dwWritten, NULL);
The pointer p is sector-aligned and points within the buffer.
If you have a situation where you want to flush all open files on the
current logical drive, this can be done by:
hFile = CreateFile("\\\\.\\c:", ....);
FlushFileBuffers(hFile);
This method causes all buffered write data for all open files on the C:
partition to be flushed and written to the disk. Note that any buffering
done by anything other than the system is not affected by this flush; any
possible file buffering that the C Run-time is doing on files opened with C
Run-time routines is unaffected.
When opening a remote file over the network, the server always caches and
ignores the no buffering flag specified by the client. This is by design.
The redirector and server cannot properly implement the full semantics of
FILE_FLAG_NO_BUFFERING over the network. In particular, the requirement for
sector-sized, sector-aligned I/O cannot be met. Therefore, when a Win32-
based application asks for FILE_FLAG_NO_BUFFERING, the redirector and
server treat this as a request for FILE_FLAG_WRITE_THROUGH. The file is not
cached at the client, writes go directly to the server and to the disk on
the server, and the read/write sizes on the network are exactly what the
application asks for. However, the file is cached on the server.
Not caching the client can have a different effect, depending on the type
of I/O. You eliminate the cache hits or read ahead, but you also may reduce
the size of transmits and receives. In general, for sequential I/O, it is a
good idea to cache on the client. For small, random access I/O, it is often
best not to cache.
Modification Type: | Minor | Last Reviewed: | 9/27/2004 |
---|
Keywords: | kbAPI kbFileIO kbinfo kbKernBase KB99794 |
---|
|