Hello,

As Damien noted, the behavior is the same for all applications using the
CreateFile Win32 API, including your .NET application.

In fact, you can see how this caching works with Windows Explorer and
Notepad only, and no code. As the MSDN documentation say, if you create a
file, delete it, and then soon re-create it again with the same name in the
same location, the Created timestamp will be reserved from the original
file.

Try this:

1. Open Windows Explorer to some directory of your choice, and also open
Notepad. Write some text to it. Close Notepad and save changes to test.txt
in the directory of your choice.
2. Take a look at the file's properties, and especially the creation time.
3. Wait some minutes, for example three.
4. Delete the file, and then immediately start Notepad, write some text, and
save your changes to test.txt.
5. Take a look at the file's properties. The creation time has been
preserved.

That said, this is not a bug in .NET, it is the way Windows (and the
CreateFile API) works. Of course, one can argue whether this is good or not,
but currently this is the way it is.

When buffered hard drives are ordered to do something, they may say it has been done before it actually has.  This improves performance as it frees up system resources to continue doing whatever it was doing, but also leads to an uncertainty that is unacceptable in some cases. Like a Database system where the order absolutely has to be executed when claimed so since otherwise a sudden powerfailure may lead to a mismatch of what the drive claimed had been written, and what it actually did manage to to before the failure.  You may stumble upon this mismatch when you delete a file, and suddenly recreate it before the file actually was deleted.