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

I think I got a case where I can reproduce this strange behaviour. At least I could provoke it several times repeatedly. Here is an example from the Windows command line (I'm using the DEL command to erase the file instead Perl's unlink; "ls" is the GnuUtil's ls.exe):

C:\>ls -l pid.txt
-rw-rw-rw-   1 user     group           4 Sep 15 16:51 pid.txt

C:\>type pid.txt
8748
C:\>perl -lwe "print(':'.localtime((stat 'pid.txt')[10]))"
:Thu Sep 15 16:45:56 2011

C:\>del pid.txt

C:\>echo 8748 >pid.txt

C:\>perl -lwe "print(':'.localtime((stat 'pid.txt')[10]))"
:Thu Sep 15 16:45:56 2011
[download]

We can see that the ctime did not change, although I erased pid.txt and created a new version! Now for a new experiment:

C:\>move pid.txt pid.old
        1 file(s) moved.

C:\>echo 8749 >pid.txt

C:\>perl -lwe "print(':'.localtime((stat 'pid.txt')[10]))"
:Thu Sep 15 16:45:56 2011
[download]

First, I moved the old pid.txt away; then a created a new one. I still get the old time stamp!!! But now look at this:

C:\>del pid.txt

C:\>perl -lwe "print(':'.localtime((stat 'pid.txt')[10]))"
Use of uninitialized value in localtime at -e line 1.
:Thu Jan  1 01:00:00 1970

C:\>echo 8750 >pid.txt

C:\>perl -lwe "print(':'.localtime((stat 'pid.txt')[10]))"
:Tue Sep 20 11:30:49 2011
[download]

I delete the file, as in the very first example before. Then I run my perl command to display the ctime of the non-existing file. Not surprisingly, I get an error message. Now I re-create pid.txt and get the ctime. THIS TIME the ctime is up-to-date!!!!

The last (third) example differs from the first one only in that I asked Windows for the ctime of the *deleted* pid.txt. This seemed to "erase" the old timestamp somehow!

This doesn't look to me like a Perl problem anymore. It seems to be a pure Windows problem. My apologies for having it posted here...

--
Ronald Fischer <ynnor@mm.st>

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

Replies are listed 'Best First'.
Re^3: Re-Creating a file does not change inode modification time (Windows) by BrowserUk (Patriarch) on Sep 20, 2011 at 13:53 UTC
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.	[reply] [d/l]
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]