You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Steve Hay <st...@uk.radan.com> on 2004/11/04 13:19:04 UTC

[PATCH] Fix t\apr-ext\finfo.t failure on Win32

Using mp2 CVS, perl-5.8.5, httpd-2.0.50:

C:\Temp\modperl-2.0>perl t/TEST -verbose t\apr-ext\finfo.t
C:\apache2\bin\Apache.EXE  -d C:/Temp/modperl-2.0/t -f 
C:/Temp/modperl-2.0/t/conf/httpd.conf -D APACHE2 -D PERL_USEITHREADS
using Apache/2.0.50 (winnt MPM)
[...]
t\apr-ext\finfo....1..15
# Running under perl version 5.008005 for MSWin32
# Current time local: Thu Nov  4 11:36:37 2004
# Current time GMT:   Thu Nov  4 11:36:37 2004
# Using Test.pm version 1.25
# Using Apache/Test.pm version 1.16
[...]
# testing : $finfo->mtime()
# expected: 1095812970
# received: 1095816570
not ok 9
[...]
FAILED test 9
        Failed 1/15 tests, 93.33% okay (less 6 skipped tests: 8 okay, 
53.33%)
Failed Test       Stat Wstat Total Fail  Failed  List of Failed
-------------------------------------------------------------------------------
t\apr-ext\finfo.t               15    1   6.67%  9

This is caused by the crap CRT library on Win32 which Perl's stat() 
function inherits broken behaviour from.  In a nutshell, whenever stat() 
gets the mtime for a file whose mtime is in the opposite Daylight Saving 
Time season to the current time and which resides on an NTFS partition, 
the result is wrong by one hour.

The test in question gets the mtime for t\lib\TestAPRlib\fimnfo.pm, 
whose mtime is sometime on 22 Sep 2004 which was British Summer Time 
here in the UK.  I'm now back in GMT, hence the result from stat() is 
wrong by one hour.  I wrote a CPAN module (Win32::UTCFileTime) which 
provides a stat() override to correct this behaviour:

C:\Temp\modperl-2.0\t\lib\TestAPRlib>perl -e "print +(stat 'finfo.pm')[9]"
1095812970
C:\Temp\modperl-2.0\t\lib\TestAPRlib>perl -MWin32::UTCFileTime -e "print 
+(Win32::UTCFileTime::stat 'finfo.pm')[9]"
1095816570

Looking at the numbers in the test output above, it looks like 
APR::Finfo's value (the "received" value) is similarly corrected, and 
hence doesn't compare to stat()'s crap value (the "expected" value).

The simplest solution is probably just to "touch" the file first so that 
it is in the same DST season as the current time.  The attached patch 
does this.

- Steve



------------------------------------------------
This email has been scanned for viruses and content by the Radan Computational Webshield Appliances.


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: [PATCH] Fix t\apr-ext\finfo.t failure on Win32

Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Steve Hay wrote:
> 
> 
>>The simplest solution is probably just to "touch" the file first so that 
>>it is in the same DST season as the current time.  The attached patch 
>>does this.
>>
> 
> Oops.  Here's the patch :)

Thanks Steve, committed.

Even though there is still a chance for a race, if the test touch happens 
a sec before the seasonal time change is rolled. But let's not worry about 
that :)

-- 
__________________________________________________________________
Stas Bekman            JAm_pH ------> Just Another mod_perl Hacker
http://stason.org/     mod_perl Guide ---> http://perl.apache.org
mailto:stas@stason.org http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org   http://ticketmaster.com

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org


Re: [PATCH] Fix t\apr-ext\finfo.t failure on Win32

Posted by Steve Hay <st...@uk.radan.com>.
Steve Hay wrote:

>The simplest solution is probably just to "touch" the file first so that 
>it is in the same DST season as the current time.  The attached patch 
>does this.
>
Oops.  Here's the patch :)

- Steve


------------------------------------------------
This email has been scanned for viruses and content by the Radan Computational Webshield Appliances.