July 6th, 2026
likeintriguing4 reactions

I opened a file with FILE_FLAG_DELETE_ON_CLOSE, but now I changed my mind

Raymond Chen

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 Chen

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.

16 comments

Sort by :
  • Fredrik Wahlgren

    Thank you! I was thinking about this exact problem and found no solution to my problem. I’m working on an encryption project where it’s important that the input file is shredded properly on successful encryption. It creates a memory mapped file and it uses BCryptGenRandom to defeat hidden compression logic that may exist. I also use the FILE_FLAG_WRITE_THROUGH to make sure it’s properly overwritten. This is what I looked for.

  • Дм Буров 23 hours ago · Edited

    As about FILE_FLAG_DELETE_ON_CLOSE - there is one another big limitation. FILE_FLAG_DELETE_ON_CLOSE makes the file process-exclusive.

    The use of that flag was clearly inspired by POSIX (UNIX) "unlink" - both file names and open handles are mere hardlinks (a la NTFS junctions, a la Linux /proc/*/fd), so you do not have to even have a file name to have a file.
    Then the file volume is auto-collected when nobody uses it anymore (unless hardware/kernel crash, maybe, but then fsck should).

    Simple and easy, IUnknown-like, IPC, when latency does not mean much. Like spawning helper processes and passing information.
    Like... passing temporary report files...

    Read more
  • ‪ ‪ 23 hours ago · Edited

    It is possible if the minimum supported version is set to Windows 10 1709.

    FILE_DISPOSITION_INFO_EX info{};
info.Flags = FILE_DISPOSITION_DO_NOT_DELETE | FILE_DISPOSITION_ON_CLOSE;
SetFileInformationByHandle(hfile, FileDispositionInfoEx, &info, sizeof(info));

Read next