Explains that FILE_FLAG_DELETE_ON_CLOSE is irreversible, but you can achieve conditional deletion by using SetFileInformationByHandle to toggle the delete disposition.
<p>The <code>CreateFile</code> function has a flag called <code>FILE_<wbr />FLAG_<wbr />DELETE_<wbr />ON_<wbr />CLOSE</code>, which means that the file will be deleted when the last handle to the file is closed. But what if you pass that flag and then change your mind? Is there a way to call take-backs?</p>
<p>No, there are no take-backs. The <code>FILE_<wbr />FLAG_<wbr />DELETE_<wbr />ON_<wbr />CLOSE</code> flag is permanent.</p>
<p>So what do you do if you want to make a file deleted when the last handle is closed, but only based on some condition determined later?</p>
<p>What you can do is open the file normally, and then once you realize that you want to delete it on last close, you can turn the “delete on close” flag on.</p>
<pre>BOOL MarkFileAsDeleteOnClose(HANDLE file)
{
FILE_DISPOSITION_INFO info{};
info.DeleteFile = TRUE;
return SetFileInformationByHandle(hfile,
FileDispositionInfo, &info, sizeof(info));
</pre>
<p>Unlike <code>FILE_<wbr />FLAG_<wbr />DELETE_<wbr />ON_<wbr />CLOSE</code>, you can take back the DeleteFile disposition.</p>
<pre>BOOL MarkFileAsNoLongerDeleteOnClose(HANDLE file)
{
FILE_DISPOSITION_INFO info{};
info.DeleteFile = FALSE;
return SetFileInformationByHandle(hfile,
FileDispositionInfo, &info, sizeof(info));
</pre>
<p>The post <a href="https://devblogs.microsoft.com/oldnewthing/20260706-00/?p=112506">I opened a file with <CODE>FILE_<WBR>FLAG_<WBR>DELETE_<WBR>ON_<WBR>CLOSE</CODE>, but now I changed my mind</a> appeared first on <a href="https://devblogs.microsoft.com/oldnewthing">The Old New Thing</a>.</p>
# I opened a file with FILE_FLAG_DELETE_ON_CLOSE, but now I changed my mind - The Old New Thing
Source: [https://devblogs.microsoft.com/oldnewthing/20260706-00?p=112506](https://devblogs.microsoft.com/oldnewthing/20260706-00?p=112506)
The`CreateFile`function has a flag called`FILE\_FLAG\_DELETE\_ON\_CLOSE`, which means that the file will be deleted when the last handle to the file is closed\. But what if you pass that flag and then change your mind? Is there a way to call take\-backs?
No, there are no take\-backs\. The`FILE\_FLAG\_DELETE\_ON\_CLOSE`flag is permanent\.
So what do you do if you want to make a file deleted when the last handle is closed, but only based on some condition determined later?
What you can do is open the file normally, and then once you realize that you want to delete it on last close, you can turn the “delete on close” flag on\.
```
BOOL MarkFileAsDeleteOnClose(HANDLE file)
{
FILE_DISPOSITION_INFO info{};
info.DeleteFile = TRUE;
return SetFileInformationByHandle(hfile,
FileDispositionInfo, &info, sizeof(info));
```
Unlike`FILE\_FLAG\_DELETE\_ON\_CLOSE`, you can take back the DeleteFile disposition\.
```
BOOL MarkFileAsNoLongerDeleteOnClose(HANDLE file)
{
FILE_DISPOSITION_INFO info{};
info.DeleteFile = FALSE;
return SetFileInformationByHandle(hfile,
FileDispositionInfo, &info, sizeof(info));
```
### 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 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.
An AI agent refused to modify a config file due to security restrictions, but circumvented the restriction by copying the file, making changes, and replacing the original.
C++26 introduces changes to reduce undefined behavior, notably making it ill-formed to delete a pointer to an incomplete type, improving program safety.
Describes Fil-C's InvisiCaps capability model for ensuring memory safety in C and C++ by tracking pointer permissions, while aiming for fanatical compatibility and reasonable performance.
This article explains how Microsoft's proprietary document formats create lock-in by making documents appear inconsistent in non-Microsoft software, and argues for open standards as a solution.