I cannot reproduce your findings?

!echo . >fred;;

print join ' | ', stat( 'fred' );;
2 | 0 | 33206 | 1 | 0 | 0 | 2 | 4 | 1316099335 | 1316099335 | 13160993
+35 |  |

unlink( 'fred' );;

open O, '>fred';;
print O 'junk';;
close O;;

print join ' | ', stat( 'fred' );;
2 | 0 | 33206 | 1 | 0 | 0 | 2 | 6 | 1316099365 | 1316099381 | 13160993
+65 |  |
[download]

I cannot reproduce your findings?

I also can "reproduce" it only sometimes (can we call it "reproduction" then?). It happens a bit more frequently, if there is not much "activity" on the file system between deleting the file and re-creating it.
The observation could be employed, if Windows XP would employ kind of a "lazy delete", i.e. if deleting would only mark the file in the directory as being deleted (which is how deletion is likely be done anyway), AND if a new file of the same name is created, just remove the deletion marker and leave anything else as it was before - including the ctime.

In Unix-speak, I would say that it just reuses the inode and forgets to update the inode modification time stamp. Windows doesn't have, as far I know, inodes, but maybe some similar feature....
-- 
Ronald Fischer <ynnor@mm.st>

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>

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.

Good point. Though I didn't see why unlink could have failed in this case (local file on C: drive, AFIK no other process having had a lock on it), it certainly doesn't harm checking this!




-- 
Ronald Fischer <ynnor@mm.st>

Some filesystems do not modify the “modification time” because it is expensive to do so.   Especially on some network filesystems, this creates a large number of disk writes to the directory blocks with no pragmatic purpose or benefit.   Therefore, these timestamps should not be regarded as a reliable indicator of modification, regardless of the operating-system.

Fully ack. You may switch off modification time update even on local NTFS file system which is enabled by default. Check if the modification date changes by running stat file multiple times if you update the file outside from perl. If yes the problem is related to the script.

Usually it's access time/atime that gets disabled, not mtime. Access might be read-only, so updating atime introduces write i/o to the FS. Modifications are by definition write i/o, so it's cost effective to update mtime also.

--Dave

Just to make it clear: I'm not talking about file modification time (mtime), but about inode modification time (ctime). Sorry if I was not precise enough about this.




-- 
Ronald Fischer <ynnor@mm.st>