Just a simple [cpan.org] guy, hacking Perl for fun and profit since way back in the last millenium. You may find me hanging around in the monestary [perlmonks.org].
What am I working on right now? Probably the Sprog project [sourceforge.net].
GnuPG key Fingerprint:
6CA8 2022 5006 70E9 2D66
AE3F 1AF1 A20A 4CC0 0851
Here's some behaviour that surprised me. I would expect this program to loop forever:
#!/usr/bin/perl
use strict;
use warnings;
my $file1 = './test_file_1';
my $file2 = './test_file_2';
my $count = 1;
while(1) {
unlink($file1); # create first file
open(FILE, ">$file1");
close(FILE);
my $t0 = (stat($file1))[9]; # wait
while(time() <= $t0) {
sleep 1;
}
my $t1 = time();
unlink($file2); # create second file
open(FILE, ">$file2");
close(FILE);
if((stat($file2))[9] <= (stat($file1))[9]) {
die sprintf(
"Timestamps: %u %u t0: %u t1: %u\n",
(stat($file2))[9], (stat($file1))[9], $t0, $t1
);
}
printf("Loop count = %u\n", $count++);
}
Given that test_file_2 is not created until the system clock is greater than the modification time on test_file_1, I would expect that the die statement would never be reached. In fact, it fails for me on multiple systems after running for a small number of minutes.
My test systems are all running Linux, and using local filesystems. I have seen this sort of funky effect when using network filesystems, presumably due to clock drift between client and fileserver. I've also run into problems where updating a file on a local NTFS partition under Windows would either not update the time or would update it to have an earlier value.
This came up because Andreas Koenig did some extensive testing to highlight random failures in XML::Simple's text suite. Now that I know it's the test itself that's at fault I just need to make it a bit more robust.
Time != time (Score:1)
Another problem with file times is that they can be older than the time at which they are made, due to shortcuts in time_second and getnanotime(). E.g., if the current time is N.009999 seconds so that time(3) returns N, then time_second may be (N-1) seconds, so file times may be 1 second older than the time at which they were made if vfs.timestamp_precision is the default.
This seems to be exactly the problem you had. In FreeBSD, there's the possibility to set the precision of filesystem timestamps to microseconds or nanoseconds (instead of just seconds). If I do so and re-run the script, then the problem does not occur, at least for 10000 iterations (formerly ~400 iterations were enough).
Re: (Score:2)