I have a user-mode program that does the following:
Marks a file for delete using NtSetInformationFile.
Closes the handle using NtClose
After a tiny delta of time, tries to NtCreateFile on the same filename.
(3) fails sometimes with STATUS_DELETE_PENDING. I assume this is because
NtClose() is not guaranteed to have completed all of IO before it returns
(as per MSDN for ZwClose).
Some possible options to ensure that (3) succeeds are:
To flush the volume where the file lies after NtClose. This will degrade
performance and is not interesting
To rename the file before closing it. This is ugly but may work.
Is there a cleaner mechanism that does not degrade performance ?
These timing windows are indeed a bit frustrating.
Another option might be to explicitly truncate the file before you close it. In theory, this should cause the cached data to be discarded and make the close happen “faster” although it still isn’t guaranteed to do so.
Finally, you could always just not delete the file and instead specify OVERWRITE or SUPERSEDE when you open it.
On 05/08/2012 09:52 PM, Arun M. Krishnakumar wrote:
(3) fails sometimes with STATUS_DELETE_PENDING. I assume this is because
NtClose() is not guaranteed to have completed all of IO before it
returns (as per MSDN for ZwClose).
I think we’ve had the same question sent to us via a different route,
but just to clearly respond with the same answer: it is true that data
is not flushed to disk before ZwClose returns, but files are deleted
before ZwClose returns, if the ZwClose is the last handle on the file.
If you get this error it is not due to pending data, and flushing the
file will not help. It is due to another handle to the same file, which
is preventing the delete from happening at the time you think the delete
should be happening.
To rename the file before closing it. This is ugly but may work.
I’ve seen others do this, it does work, and it is ugly.