Explains how to use the COPY_FILE_NO_BUFFERING flag with CopyFileEx and CopyFile2 to copy files using unbuffered handles, and why the progress callback cannot be used to change buffering after the handles are opened.
<p>A customer was copying a file with <code>CopyFile</code>, but they wanted the file handles to be opened as <code>FILE_<wbr />FLAG_<wbr />NO_<wbr />BUFFERING</code>.</p>
<p>We saw some time ago that <a title="How can I perform a CopyFile, but also flush the file buffers before the destination handle is closed?" href="https://devblogs.microsoft.com/oldnewthing/20221007-00/?p=107261"> you can use the progress callback to <code>CopyFileEx</code> or <code>CopyFile2</code> to flush the output handle</a>. Maybe we can use the progress callback to open the handle as unbuffered?</p>
<p>Nope, that doesn’t work because the progress callback gives you the already-opened handle. You can’t change its buffering flag after the fact.</p>
<p>But that’s okay, because <code>CopyFileEx</code> and <code>CopyFile2</code> also have a flags parameter, and one of the flags is <code>COPY_<wbr />FILE_<wbr />NO_<wbr />BUFFERING</code>, which means that the handle should be opened as <code>FILE_<wbr />FLAG_<wbr />NO_<wbr />BUFFERING</code>.</p>
<pre>BOOL success = CopyFileEx(
sourceFilePath, destinationFilePath,
nullptr, nullptr, nullptr,
COPY_FILE_NO_BUFFERING);
</pre>
<p>You can do the same with <code>CopyFile2</code>, but the flags are in the options structure.</p>
<pre>COPYFILE2_EXTENDED_PARAMETERS parameters{};
parameters.dwSize = sizeof(parameters);
parameters.dwCopyFlags = COPY_FILE_NO_BUFFERING;
HRESULT hr = CopyFile2(sourceFilePath, destinationFilePath, &parameters);
</pre>
<p>The post <a href="https://devblogs.microsoft.com/oldnewthing/20260810-00/?p=112600">How can I perform a <CODE>Copy­File</CODE> in unbuffered mode?</a> appeared first on <a href="https://devblogs.microsoft.com/oldnewthing">The Old New Thing</a>.</p>
# How can I perform a CopyFile in unbuffered mode? - The Old New Thing
Source: [https://devblogs.microsoft.com/oldnewthing/20260810-00?p=112600](https://devblogs.microsoft.com/oldnewthing/20260810-00?p=112600)
A customer was copying a file with`CopyFile`, but they wanted the file handles to be opened as`FILE\_FLAG\_NO\_BUFFERING`\.
We saw some time ago that[you can use the progress callback to`CopyFileEx`or`CopyFile2`to flush the output handle](https://devblogs.microsoft.com/oldnewthing/20221007-00/?p=107261)\. Maybe we can use the progress callback to open the handle as unbuffered?
Nope, that doesn’t work because the progress callback gives you the already\-opened handle\. You can’t change its buffering flag after the fact\.
But that’s okay, because`CopyFileEx`and`CopyFile2`also have a flags parameter, and one of the flags is`COPY\_FILE\_NO\_BUFFERING`, which means that the handle should be opened as`FILE\_FLAG\_NO\_BUFFERING`\.
```
BOOL success = CopyFileEx(
sourceFilePath, destinationFilePath,
nullptr, nullptr, nullptr,
COPY_FILE_NO_BUFFERING);
```
You can do the same with`CopyFile2`, but the flags are in the options structure\.
```
COPYFILE2_EXTENDED_PARAMETERS parameters{};
parameters.dwSize = sizeof(parameters);
parameters.dwCopyFlags = COPY_FILE_NO_BUFFERING;
HRESULT hr = CopyFile2(sourceFilePath, destinationFilePath, ¶meters);
```
### Category
### Topics
## Author
Raymond has been involved in the evolution of Windows for more than 30 years\. In 2003, he began a Web site known as The Old New Thing which has grown in popularity far beyond his wildest imagination, a development which still gives him the heebie\-jeebies\. The Web site spawned a book, coincidentally also titled The Old New Thing \(Addison Wesley 2007\)\. He occasionally appears on the Windows Dev Docs Twitter account to tell stories which convey no useful information\.
This article explains how Go's io.Copy automatically uses sendfile and splice for zero-copy file transfers over TCP, and demonstrates how wrapping a file in a plain io.Reader—e.g., for logging—quietly disables this optimization, causing a significant performance drop. Benchmarks and strace output illustrate the impact.
Technical analysis of the interconversion between std::function and std::copyable_function in C++26, discussing implementation approaches and performance trade-offs, with specific note that libstdc++ currently uses a less optimal approach.
Explains that FILE_FLAG_DELETE_ON_CLOSE is irreversible, but you can achieve conditional deletion by using SetFileInformationByHandle to toggle the delete disposition.
This article explains how the WM_COPYDATA message, introduced for 32-bit Windows, was retrofitted onto 16-bit Windows 3.1 by taking advantage of the shared address space, requiring no changes for inter-16-bit communication.
This article explains that Windows does not have a built-in concept of binary vs. text mode at the OS level; such distinctions are handled by runtime libraries like the C runtime. It clarifies that all files are treated as bytes by Windows and that content transformations must be done manually or via libraries.