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?

On Aug 7, 2:15 pm, msci...@osmose.com wrote:

> 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

On Aug 7, 10:51 am, Damien  wrote:

> On Aug 7, 2:15 pm, msci...@osmose.com wrote:
>
> > 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


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?

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 Jrvinen
C# MVP
Helsinki, Finland
janij@removethis.dystopia.fi
http://www.saunalahti.fi/janij/

On Tue, 07 Aug 2007 17:27:48 +0200,  wrote:


> On Aug 7, 10:51 am, Damien  wrote:
>> On Aug 7, 2:15 pm, msci...@osmose.com wrote:
>>
>> > 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
>
> 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.

-- 
Happy coding!
Morten Wennevik [C# MVP]

Ok, so FileInfo.LastWriteTime it is.

Thank you everyone.