File creation time

[roger.dahlstrom]

My apologies in advance if this is the wrong group for this - it's
tough to know where to put it...

Steps to reproduce:
1. Navigate to c:\
2. Create a new text file (test.txt)
3. Put something in it (like "This is a line of text")
4. Right-click, properties, verify create date/time.
5. Delete file
6. Wait a minute or two
7. Re-create c:\test.txt (with the same or new text)
8. Right-click, properties.

Now, the create date/time should be the time you created the second
file, not the first one. However (at least on the several systems I
tested on), the create date remains the same as the first file created,
and only the last modified date is correct.

Is there something I can do to correct this behavior, or is it just
something I have to live with?

 

[Wesley Vogel]

Name the second .txt file something else.

--
Hope this helps. Let us know.

Wes
MS-MVP Windows Shell/User

In

 

[roger.dahlstrom]

Not really what I'm looking for...

 

[Bob I]

It doesn't happen to me using "New Text Document.txt" as the default
filename in both cases.

 

[Guest]

If you wait longer than one minute, say, One hour, does it still have the
same 'created' time?

 

[roger.dahlstrom]

If you wait longer than one minute, say, One hour, does it still have the same 'created' time?

I have tested it up to one day using test.txt as the file name, and it
still did it.

 

[roger.dahlstrom]

It doesn't happen to me using "New Text Document.txt" as the default filename in both cases.

Are you sure you're looking at created date rather than last modified?
Because the last modified and accessed times both work as you would
expect them to - it's only the create date/time.

 

[Bob I]

I looked at "Properties" and all three date/times were different between
the 2 files.

 

[Stubbo_of_Oz]

My apologies in advance if this is the wrong group for this - it's
tough to know where to put it...

Steps to reproduce:
1. Navigate to c:\
2. Create a new text file (test.txt)
3. Put something in it (like "This is a line of text")
4. Right-click, properties, verify create date/time.
5. Delete file
6. Wait a minute or two
7. Re-create c:\test.txt (with the same or new text)
8. Right-click, properties.

Now, the create date/time should be the time you created the second
file, not the first one. However (at least on the several systems I
tested on), the create date remains the same as the first file created,
and only the last modified date is correct.

Is there something I can do to correct this behavior, or is it just
something I have to live with?

I can duplicate your problem if I delete the file to the trash can

But if I delete it from the trash can altogether, a new create date
appears.

So it must be picking up the file details from the trash can

So, when you delete do a premanent delete rather than a delete to
trash can.

 

[David Candy]

This is what is needed for windows to maintain date and time from programs that don't fix dates and times when they write files by writing a new name, delete old file, rename new file to old name.

 

[roger.dahlstrom]

I am able to reproduce this issue at will either on network drives,
permanent deletes, delete to recycle bin, delete programatically,
delete via "rm" using cygwin, and new file creation via something like
BCP.

Also, what do you mean by "this is what is needed"? Why can't the file
system maintain the dates and times of the files? Wouldn't you think
that is a basic function of a file system?

 

[David Candy]

It does, that's why it does what I said it does. If it didn't then programs would mess it up. However it is only a few seconds. I explained why and people who don't read what I write shit me. It was only one (long) sentence. Delete to Recycle does nothing to change a date as they aren't deleted but moved and renamed.

Remarks
The FAT and NTFS file systems support the file creation, last access, and last write time values.

Windows NT/2000/XP: If you rename or delete a file, then restore it shortly thereafter, Windows NT searches the cache for file information to restore. Cached information includes its short/long name pair and creation time.

Note Not all file systems can record creation and last access time and not all file systems record them in the same manner. For example, on Windows NT FAT, create time has a resolution of 10 milliseconds, write time has a resolution of 2 seconds, and access time has a resolution of 1 day (really, the access date). On NTFS, access time has a resolution of 1 hour. Therefore, GetFileTime may not return the same file time information set using the SetFileTime function. Furthermore, FAT records times on disk in local time. However, NTFS records times on disk in UTC. For more information, see File Times.

 

[Bob I]

It would appear that something on your system is causing the issue.
Maybe you are using Norton Protected Recycle Bin or some thing?

 

[roger.dahlstrom]

However it is only a few seconds

Incorrect. Read the rest of the thread. I am able to reproduce this
over a matter of at least 24 hours.

Delete to Recycle does nothing to change a date

Not applicable. Read the thread. I have tried it with recycle bin,
emptying the recycle bin, permanent delete first, progmatic delete,
delete with the "rm" tool with cygwin, delete over a network share, and
a delete via mssql's bcp utility (which deletes a file then recreates
it).

It would appear that something on your system is causing the issue.

I do not use anything from Norton, and have reproduced this on multiple
workstations both on networks and standalone, re-imaged, and
reinstalled fresh.