File.Delete / Recreating File bug

[mscirri]

I have a C# application that calls File.Delete(path) to delete an
existing file. This works great. When the application is closed I then
create a file in the same location with the same name. This also works
but when I look at the properties, it has a Created date of
yesterday. If I go into Explorer and delete the file and then let the
application recreate it it works fine.

Any thoughts?

 

[Damien]

I have a C# application that calls File.Delete(path) to delete an
existing file. This works great. When the application is closed I then
create a file in the same location with the same name. This also works
but when I look at the properties, it has a Created date of
yesterday. If I go into Explorer and delete the file and then let the
application recreate it it works fine.

Any thoughts?

Look in the Files section of the Remarks section of this:
http://msdn2.microsoft.com/en-us/library/aa363858.aspx

(CreateFile is the underlying Win32 API function used by .Net to
create files).

Specifically, the comment:

If you rename or delete a file and then restore it shortly afterward,
the system searches the cache for file information to restore. Cached
information includes its short/long name pair and creation time.

(This message is an almost exact repreat of a message I posted June
12th 2006)

Damien

 

[mscirri]

Look in the Files section of the Remarks section of this:http://msdn2.microsoft.com/en-us/library/aa363858.aspx

(CreateFile is the underlying Win32 API function used by .Net to
create files).

Specifically, the comment:

If you rename or delete a file and then restore it shortly afterward,
the system searches the cache for file information to restore. Cached
information includes its short/long name pair and creation time.

(This message is an almost exact repreat of a message I posted June
12th 2006)

Damien

What exactly do you mean by restored? All I am doing is creating a
file with the same name. THe contents may be the same or they may not.
Is that all that is needed for the system to search the cache is the
same full file name?

 

[Jani Järvinen [MVP]]

Hello,

What exactly do you mean by restored? All I am doing is creating a
file with the same name. THe contents may be the same or they may not.
Is that all that is needed for the system to search the cache is the
same full file name?

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.

--
Regards,

Mr. Jani Järvinen
C# MVP
Helsinki, Finland
(e-mail address removed)
http://www.saunalahti.fi/janij/

 

[Morten Wennevik [C# MVP]]

What exactly do you mean by restored? All I am doing is creating a
file with the same name. THe contents may be the same or they may not.
Is that all that is needed for the system to search the cache is the
same full file name?

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.

 

[mscirri]

Ok, so FileInfo.LastWriteTime it is.

Thank you everyone.