Re^3: Re-Creating a file does not change inode modification time (Windows)

I can reproduce these findings:

c:\test>dir fred
15/09/2011  16:09                 6 fred

c:\test>dir /T:C fred
15/09/2011  16:09                 6 fred

c:\test>dir /T:A fred
15/09/2011  16:09                 6 fred

c:\test>del fred

c:\test>echo . > fred

c:\test>dir fred
20/09/2011  14:41                 4 fred

c:\test>dir /T:C fred
15/09/2011  16:09                 4 fred
[download]

It seems to be explained by file system caching. This snippet from MS:

Timestamps are updated at various times and for various reasons. The only guarantee about a file timestamp is that the file time is correctly reflected when the handle that makes the change is closed. .... The NTFS file system delays updates to the last access time for a file by up to 1 hour after the last access.

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

Comment on Re^3: Re-Creating a file does not change inode modification time (Windows) Download Code

Replies are listed 'Best First'.
Re^4: Re-Creating a file does not change inode modification time (Windows) by Anonymous Monk on May 07, 2014 at 16:04 UTC
This is a misfeature in Windows. MSDN documents it on the page for GetFileTime (available via Google search as "GetFileTime" site:msdn.microsoft.com if the page moves again): If you rename or delete a file, then restore it shortly thereafter, Windows searches the cache for file information to restore. Cached information includes its short/long name pair and creation time. Since this is a cache, that might explain OP's observation that other activity influences whether the creation time is reused.	[reply]
Re^4: Re-Creating a file does not change inode modification time (Windows) by rovf (Priest) on Sep 20, 2011 at 15:52 UTC
Your quotation from MS is interesting, but I think it does not explain the issue, for two reason: If the timestamp would be updated after the file handle is closed, a DEL followed by an "ECHO ...>FILE" should result in a correct time stamp. If the effect would be due to an 1-hour-caching delay, the effect should be gone after one hour, but it isn't. Moreover, it even survives a reboot. What is likely correct is the observation, that this is NTFS specific. On a networked drive, the effect does not occur. It is also not specific to Windows XP. We can reproduce it now also on Windows 7 without problems. I think we just have to accept the fact that, on Windows, creating a file doesn't mean that the ctime is set to the creatin time; the ctime may be a much older timestamp, if the file system is NTFS and a file of the same name had existed some arbitrary time in the past. -- Ronald Fischer <ynnor@mm.st>	[reply] [d/l]