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 2003/12/12 18:46:11 UTC

[mp2] apr/finfo test 10 fails on Windows

I've just run the mp2 testsuite using the latest CVS version and got one 
test failure:

=====
 >perl t/TEST -verbose apr/finfo.t
[...]
# Running under perl version 5.008002 for MSWin32
# Current time local: Fri Dec 12 17:36:14 2003
# Current time GMT:   Fri Dec 12 17:36:14 2003
# Using Test.pm version 1.24
[...]
# testing : $r->finfo->atime()
# expected: 1071249888
# received: 1071250580
not ok 10
[...]
FAILED test 10
        Failed 1/17 tests, 94.12% okay (less 6 skipped tests: 10 okay, 
58.82%)
Failed Test Stat Wstat Total Fail  Failed  List of Failed
-------------------------------------------------------------------------------
apr/finfo.t               17    1   5.88%  10
6 subtests skipped.
=====

Nothing relevant appears in the error log.

Versions: WinXP, MSVC6, perl-5.8.2, apache-2.0.48, mod_perl-cvs

- Steve



------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only.  If you have received this message in error or there are any problems, please notify the sender immediately.  The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden.  Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.


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


Re: [PATCH] Re: [mp2] apr/finfo test 10 fails on Windows

Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 16 Dec 2003, Steve Hay wrote:

> Steve Hay wrote:
>
> >It's bizarre that it always seems to work for Randy,
> >
> One thought just occurred to me that might explain the difference: Are
> you using Visual Studio 7, Randy?  I'm using Visual Studio 6 (Service
> Pack 5).  Maybe the Win32 API functions, or even the MS C run-time
> library implementations, have changed in this area?
>
> And/or different OS's?  I'm running Windows XP Service Pack 1.

I'm also using Visual Studio 6, Service Pack 5 (there's
potential binary incompatibilities between ActivePerl,
compiled with VC++ 6, and extensions built with VC++ 7).
And I'm on XP - I forget which Service Pack, but I'm using
the automatic update thing of XP, so it should be at the
most recent level.

-- 
best regards,
randy

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


Re: [PATCH] Re: [mp2] apr/finfo test 10 fails on Windows

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

>It's bizarre that it always seems to work for Randy,
>
One thought just occurred to me that might explain the difference: Are 
you using Visual Studio 7, Randy?  I'm using Visual Studio 6 (Service 
Pack 5).  Maybe the Win32 API functions, or even the MS C run-time 
library implementations, have changed in this area?

And/or different OS's?  I'm running Windows XP Service Pack 1.

- Steve



------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only.  If you have received this message in error or there are any problems, please notify the sender immediately.  The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden.  Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.


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


Re: [PATCH] Re: [mp2] apr/finfo test 10 fails on Windows

Posted by Stas Bekman <st...@stason.org>.
Steve Hay wrote:
> Randy Kobes wrote:
> 
> 
>>I'm at a loss too ... Perhaps it may be due to my running
>>things on a FAT32 file system, and Steve on NTFS?
>>
> 
> That must be it!
> 
> I am indeed running on NTFS.  The sample C program that I posted a short 
> while ago gives inconsistent results for seemingly any file on my C: 
> drive (NTFS).  If I change it to test a file on the A: drive (FAT) 
> instead then both functions - GetFileInformationByHandle() and stat() - 
> always seem to give the same result.
> 
> At least that's explained what's going on.  I'm not just going mad!

So you probably want to add to the patch a comment:

# atime is wrong on NTFS (but correct on FAT32)

just before the skip hash.

__________________________________________________________________
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] Re: [mp2] apr/finfo test 10 fails on Windows

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

>I'm at a loss too ... Perhaps it may be due to my running
>things on a FAT32 file system, and Steve on NTFS?
>
That must be it!

I am indeed running on NTFS.  The sample C program that I posted a short 
while ago gives inconsistent results for seemingly any file on my C: 
drive (NTFS).  If I change it to test a file on the A: drive (FAT) 
instead then both functions - GetFileInformationByHandle() and stat() - 
always seem to give the same result.

At least that's explained what's going on.  I'm not just going mad!

- Steve



------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only.  If you have received this message in error or there are any problems, please notify the sender immediately.  The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden.  Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.


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


Re: [PATCH] Re: [mp2] apr/finfo test 10 fails on Windows

Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 16 Dec 2003, Steve Hay wrote:

> Geoffrey Young wrote:
>
> >># testing : $r->finfo->atime()
> >># expected: 1071570596
> >># received: 1071571230
> >
> >>where the 1071570596 time is the time at which I unpacked and built the
> >>mod_perl 2 cvs snapshot, and the (offending) 1071571230 time is the time
> >>at which I am running the test.
> >>
> >>The "expected" time (1071570596) is that produced by Perl's built-in
> >>stat(), while the "received" time (1071571230) is that produced by
> >>Apache's $r->finfo()->stat().  It is definitely Apache that is wrong
> >>here, because Windows explorer agrees with Perl that the last access
> >>time is 1071570596 -- the time at which mod_perl 2 was built.
> >>
> >>
> >
> >I might have an answer here.  APR is using the windows
> >API for atime, specifically &wininfo->ftLastAccessTime,
> >where wininfo is populated by GetFileInformationByHandle.
> >in the GetFileInformationByHandle docs it says this:
> >
> >ftLastAccessTime
> >    A FILETIME structure. For a file, the structure
> > specifies when the file
> >was last read from or written to. For a directory, the
> >structure specifies when the directory was created. For
> >both files and directories, the specified date will be
> >correct, but the time of day will always be set to
> >midnight. If the underlying file system does not support
> >last access time, this member is zero.
> >
> >so, Apache uses this API.  does 1071570596 refer to midnight on your system?
> >  probably not :)
> >
> Indeed not.  Neither of the times involved is midnight:-
>
> C:\Temp>perl -e "print scalar localtime 1071570596"
> Tue Dec 16 10:29:56 2003
> C:\Temp>perl -e "print scalar localtime 1071571230"
> Tue Dec 16 10:40:30 2003
>
> >nevertheless, perl seems to be using a simple fstat call,
> >and not GetFileInformationByHandle.  hence the descrepancy I'd think.
> >
> >from all this I gather that at least one thing is clear: $finfo->atime() is
> >documented to be inconsistent with perl's stat() atime on Win32, even if it
> >sometimes works.
> >
> Yes, I think you're correct.  As an experiment I tried running this
[ ... ]
> The output is exactly consistent with the results I reported Apache &
> Perl giving above:
>
> C:\Temp>stattest.exe
> GFIBH(): 1071571230
> stat(): 1071570596
>
> It's bizarre that it always seems to work for Randy, and I really don't
> understand where that strange time from Apache
> (GetFileInformationByHandle()) is coming from -- it certainly isn't
> midnight however you look at it! -- but you're right that this must be
> where the discrepancy is coming from.

I'm at a loss too ... Perhaps it may be due to my running
things on a FAT32 file system, and Steve on NTFS? In any
event, the above seems to explain it, so unless there's
any objections, I'll add the patch below.

> >
> >so, I'd suggest skipping that test on Win32.  at least this time we have a
> >(half) decent explanation :)
> >
> I agree.  Patch:
>
> =====
> --- t/response/TestAPR/finfo.pm.orig    2003-12-01 19:16:52.000000000 +0000
> +++ t/response/TestAPR/finfo.pm    2003-12-16 15:27:32.097496000 +0000
> @@ -57,7 +57,7 @@
>
>          # skip certain tests on Win32 (and others?)
>          my %skip =  WIN32 ?
> -            (map {$_ => 1} qw(device inode user group) ) : ();
> +            (map {$_ => 1} qw(device inode user group atime) ) : ();
>
>          # compare stat fields between perl and apr_stat
>          {
> =====


-- 
best regards,
randy


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


[PATCH] Re: [mp2] apr/finfo test 10 fails on Windows

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

>># testing : $r->finfo->atime()
>># expected: 1071570596
>># received: 1071571230
>>    
>>
>
>  
>
>>where the 1071570596 time is the time at which I unpacked and built the 
>>mod_perl 2 cvs snapshot, and the (offending) 1071571230 time is the time 
>>at which I am running the test.
>>
>>The "expected" time (1071570596) is that produced by Perl's built-in 
>>stat(), while the "received" time (1071571230) is that produced by 
>>Apache's $r->finfo()->stat().  It is definitely Apache that is wrong 
>>here, because Windows explorer agrees with Perl that the last access 
>>time is 1071570596 -- the time at which mod_perl 2 was built.
>>    
>>
>
>I might have an answer here.  APR is using the windows API for atime,
>specifically &wininfo->ftLastAccessTime, where wininfo is populated by
>GetFileInformationByHandle.  in the GetFileInformationByHandle docs it says
>this:
>
>ftLastAccessTime
>    A FILETIME structure. For a file, the structure specifies when the file
>was last read from or written to. For a directory, the structure specifies
>when the directory was created. For both files and directories, the
>specified date will be correct, but the time of day will always be set to
>midnight. If the underlying file system does not support last access time,
>this member is zero.
>
>so, Apache uses this API.  does 1071570596 refer to midnight on your system?
>  probably not :)  
>
Indeed not.  Neither of the times involved is midnight:-

C:\Temp>perl -e "print scalar localtime 1071570596"
Tue Dec 16 10:29:56 2003
C:\Temp>perl -e "print scalar localtime 1071571230"
Tue Dec 16 10:40:30 2003

>nevertheless, perl seems to be using a simple fstat call,
>and not GetFileInformationByHandle.  hence the descrepancy I'd think.
>
>from all this I gather that at least one thing is clear: $finfo->atime() is
>documented to be inconsistent with perl's stat() atime on Win32, even if it
>sometimes works.
>
Yes, I think you're correct.  As an experiment I tried running this 
little C program that I wrote:

=====
#include <windows.h>
#include <stdio.h>
#include <time.h>
#include <sys/types.h>
#include <sys/stat.h>
static const ULONGLONG clunks_per_second = 10000000L;
static const SYSTEMTIME base_st = { 1970, 1, 0, 1, 0, 0, 0, 0 };
void main(void) {
    char *file = "C:\\Temp\\modperl-2.0-807\\t\\htdocs\\index.html";
    HANDLE hndl;
    BY_HANDLE_FILE_INFORMATION bhfi;
    static FILETIME base_ft;
    ULARGE_INTEGER it;
    time_t ut;
    struct stat st_buf;
    if ((hndl = CreateFile(file, GENERIC_READ, FILE_SHARE_READ, NULL,
            OPEN_EXISTING, FILE_FLAG_BACKUP_SEMANTICS, NULL)) ==
            INVALID_HANDLE_VALUE)
        printf("CreateFile() failed\n");
    if (!GetFileInformationByHandle(hndl, &bhfi))
        printf("GetFileInformationByHandle() failed\n");
    CloseHandle(hndl);
        if (!SystemTimeToFileTime(&base_st, &base_ft))
            printf("SystemTimeToFileTime() failed\n");
    it.QuadPart  = ((ULARGE_INTEGER *)&bhfi.ftLastAccessTime)->QuadPart;
    it.QuadPart -= ((ULARGE_INTEGER *)&base_ft)->QuadPart;
    it.QuadPart /= clunks_per_second;
    ut = it.LowPart;
    printf("GFIBH(): %d\n", ut);

    if (stat(file, &st_buf) == -1)
        printf("stat() failed\n");
    printf("stat(): %d\n", st_buf.st_atime);
}
=====

The output is exactly consistent with the results I reported Apache & 
Perl giving above:

C:\Temp>stattest.exe
GFIBH(): 1071571230
stat(): 1071570596

It's bizarre that it always seems to work for Randy, and I really don't 
understand where that strange time from Apache 
(GetFileInformationByHandle()) is coming from -- it certainly isn't 
midnight however you look at it! -- but you're right that this must be 
where the discrepancy is coming from.

>
>so, I'd suggest skipping that test on Win32.  at least this time we have a
>(half) decent explanation :)
>
I agree.  Patch:

=====
--- t/response/TestAPR/finfo.pm.orig    2003-12-01 19:16:52.000000000 +0000
+++ t/response/TestAPR/finfo.pm    2003-12-16 15:27:32.097496000 +0000
@@ -57,7 +57,7 @@
 
         # skip certain tests on Win32 (and others?)
         my %skip =  WIN32 ?
-            (map {$_ => 1} qw(device inode user group) ) : ();
+            (map {$_ => 1} qw(device inode user group atime) ) : ();
 
         # compare stat fields between perl and apr_stat
         {
=====

- Steve



------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only.  If you have received this message in error or there are any problems, please notify the sender immediately.  The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden.  Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.


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


Re: [mp2] apr/finfo test 10 fails on Windows

Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 
> # testing : $r->finfo->atime()
> # expected: 1071570596
> # received: 1071571230

> where the 1071570596 time is the time at which I unpacked and built the 
> mod_perl 2 cvs snapshot, and the (offending) 1071571230 time is the time 
> at which I am running the test.
> 
> The "expected" time (1071570596) is that produced by Perl's built-in 
> stat(), while the "received" time (1071571230) is that produced by 
> Apache's $r->finfo()->stat().  It is definitely Apache that is wrong 
> here, because Windows explorer agrees with Perl that the last access 
> time is 1071570596 -- the time at which mod_perl 2 was built.

I might have an answer here.  APR is using the windows API for atime,
specifically &wininfo->ftLastAccessTime, where wininfo is populated by
GetFileInformationByHandle.  in the GetFileInformationByHandle docs it says
this:

ftLastAccessTime
    A FILETIME structure. For a file, the structure specifies when the file
was last read from or written to. For a directory, the structure specifies
when the directory was created. For both files and directories, the
specified date will be correct, but the time of day will always be set to
midnight. If the underlying file system does not support last access time,
this member is zero.

so, Apache uses this API.  does 1071570596 refer to midnight on your system?
  probably not :)  nevertheless, perl seems to be using a simple fstat call,
and not GetFileInformationByHandle.  hence the descrepancy I'd think.

from all this I gather that at least one thing is clear: $finfo->atime() is
documented to be inconsistent with perl's stat() atime on Win32, even if it
sometimes works.

so, I'd suggest skipping that test on Win32.  at least this time we have a
(half) decent explanation :)

--Geoff

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/base/by_handle_file_information_str.asp


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


Re: [mp2] apr/finfo test 10 fails on Windows

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

>Looks like I'll have to give ActivePerl 807 a whirl tomorrow, then.
>
I've now tried ActivePerl 807 too, and it still fails.

Just to be really sure I've also rebuilt the whole Apache/Perl/mod_perl 
setup from fresh using perl-5.8.2:

- Built apache-2.0.48
- Built perl-5.8.2
- Built libwin32
- Installed apxs
- Built IPC-Run3, HTML-Tagset, HTML-Parser, URI, LWP
- Built mod_perl 2

and then again using ActivePerl 807:

- Built apache-2.0.48
- Installed ActivePerl 807 (which already has libwin32, IPC-Run3 and LWP 
in it)
- Installed apxs
- Built mod_perl 2

Both of these clean setups (in different locations) still fail apr/finfo 
test 10.  In each case, running the test in verbose mode produces output 
like this:

# testing : $r->finfo->atime()
# expected: 1071570596
# received: 1071571230
not ok 10
# testing : $r->finfo->mtime()
# expected: 1071570596
# received: 1071570596
ok 11
# testing : $r->finfo->ctime()
# expected: 1071570596
# received: 1071570596

where the 1071570596 time is the time at which I unpacked and built the 
mod_perl 2 cvs snapshot, and the (offending) 1071571230 time is the time 
at which I am running the test.

The "expected" time (1071570596) is that produced by Perl's built-in 
stat(), while the "received" time (1071571230) is that produced by 
Apache's $r->finfo()->stat().  It is definitely Apache that is wrong 
here, because Windows explorer agrees with Perl that the last access 
time is 1071570596 -- the time at which mod_perl 2 was built.

Are you definitely using apache-2.0.48?  Maybe you've got a later cvs 
version which has fixed this?

I'm at a loss what else to try now.

- Steve



------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only.  If you have received this message in error or there are any problems, please notify the sender immediately.  The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden.  Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.


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


Re: [mp2] apr/finfo test 10 fails on Windows

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

>On Mon, 15 Dec 2003, Steve Hay wrote:
>
>  
>
>>I just retested with the cvs version that I grabbed last Friday and
>>found that it worked, but only once: thereafter it fails again!
>>
>>More testing shows that if I "touch" the file that it is stat()'ing
>>(t/htdocs/index.html) to give it file times of >1 hour ago then the
>>offending test works, but any repeat tests immediately after that fail
>>again:
>>
>>C:\Temp\modperl-2.0>\cygwin\bin\touch 12151545 t/htdocs/index.html
>>C:\Temp\modperl-2.0>perl t/TEST -verbose apr/finfo.t
>>[OK]
>>C:\Temp\modperl-2.0>perl t/TEST -verbose apr/finfo.t
>>[Fails test 10]
>>C:\Temp\modperl-2.0>perl t/TEST -verbose apr/finfo.t
>>[Fails test 10]
>>C:\Temp\modperl-2.0>perl t/TEST -verbose apr/finfo.t
>>[Fails test 10]
>>...
>>C:\Temp\modperl-2.0>\cygwin\bin\touch 12151545 t/htdocs/index.html
>>C:\Temp\modperl-2.0>perl t/TEST -verbose apr/finfo.t
>>[OK]
>>C:\Temp\modperl-2.0>perl t/TEST -verbose apr/finfo.t
>>[Fails test 10]
>>C:\Temp\modperl-2.0>perl t/TEST -verbose apr/finfo.t
>>[Fails test 10]
>>C:\Temp\modperl-2.0>perl t/TEST -verbose apr/finfo.t
>>[Fails test 10]
>>...
>>
>>Bizarre!  Do you observe this behaviour?  If not, then I'll give
>>ActivePerl 807 a try myself.
>>    
>>
>
>No, I don't see this, even running 3 tests in a row like
>this, and even if I edit the file so as to give it a new
>modification time ... You're right - that's very strange!
>
>After you run the test, does the file modification time of
>index.html change?
>
No (well, not unless I've changed it with touch or utime() ;)

>
>  
>
>>I get the same thing happening with the latest cvs which I've just
>>grabbed (with your patch for modperl_mgv.c).
>>
>>An obvious "fix" is to utime() the file in question to set the file
>>times to >1 hour ago:
>>    
>>
>
>I've heard, but I forget in what context, problems with file
>times less than 1 hour on Win32, so this does ring a bell ..
>
There are definitely problems with stat()'ing files modified in the 
"opposite" Daylight Saving Time "season" (Daylight Time vs Standard 
Time), but this file is modified today so is obviously the same season, 
and I'm in GMT Standard Time too, so there isn't even any Time Zone 
involved.

The only other problem that I'm aware of is that the granularity of file 
times in FAT file systems is 2 seconds, but, again, that's irrelevant 
here as I'm on NTFS.

Looks like I'll have to give ActivePerl 807 a whirl tomorrow, then.

- Steve



------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only.  If you have received this message in error or there are any problems, please notify the sender immediately.  The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden.  Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.


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


Re: [mp2] apr/finfo test 10 fails on Windows

Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Mon, 15 Dec 2003, Steve Hay wrote:

> I just retested with the cvs version that I grabbed last Friday and
> found that it worked, but only once: thereafter it fails again!
>
> More testing shows that if I "touch" the file that it is stat()'ing
> (t/htdocs/index.html) to give it file times of >1 hour ago then the
> offending test works, but any repeat tests immediately after that fail
> again:
>
> C:\Temp\modperl-2.0>\cygwin\bin\touch 12151545 t/htdocs/index.html
> C:\Temp\modperl-2.0>perl t/TEST -verbose apr/finfo.t
> [OK]
> C:\Temp\modperl-2.0>perl t/TEST -verbose apr/finfo.t
> [Fails test 10]
> C:\Temp\modperl-2.0>perl t/TEST -verbose apr/finfo.t
> [Fails test 10]
> C:\Temp\modperl-2.0>perl t/TEST -verbose apr/finfo.t
> [Fails test 10]
> ...
> C:\Temp\modperl-2.0>\cygwin\bin\touch 12151545 t/htdocs/index.html
> C:\Temp\modperl-2.0>perl t/TEST -verbose apr/finfo.t
> [OK]
> C:\Temp\modperl-2.0>perl t/TEST -verbose apr/finfo.t
> [Fails test 10]
> C:\Temp\modperl-2.0>perl t/TEST -verbose apr/finfo.t
> [Fails test 10]
> C:\Temp\modperl-2.0>perl t/TEST -verbose apr/finfo.t
> [Fails test 10]
> ...
>
> Bizarre!  Do you observe this behaviour?  If not, then I'll give
> ActivePerl 807 a try myself.

No, I don't see this, even running 3 tests in a row like
this, and even if I edit the file so as to give it a new
modification time ... You're right - that's very strange!

After you run the test, does the file modification time of
index.html change?

> I get the same thing happening with the latest cvs which I've just
> grabbed (with your patch for modperl_mgv.c).
>
> An obvious "fix" is to utime() the file in question to set the file
> times to >1 hour ago:

I've heard, but I forget in what context, problems with file
times less than 1 hour on Win32, so this does ring a bell ..

-- 
best regards,
randy

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


Re: [mp2] apr/finfo test 10 fails on Windows

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

>On Fri, 12 Dec 2003, Steve Hay wrote:
>
>  
>
>>I've just run the mp2 testsuite using the latest CVS version and got one
>>test failure:
>>
>>=====
>> >perl t/TEST -verbose apr/finfo.t
>>[...]
>># Running under perl version 5.008002 for MSWin32
>># Current time local: Fri Dec 12 17:36:14 2003
>># Current time GMT:   Fri Dec 12 17:36:14 2003
>># Using Test.pm version 1.24
>>[...]
>># testing : $r->finfo->atime()
>># expected: 1071249888
>># received: 1071250580
>>not ok 10
>>[...]
>>FAILED test 10
>>        Failed 1/17 tests, 94.12% okay (less 6 skipped tests: 10 okay,
>>58.82%)
>>Failed Test Stat Wstat Total Fail  Failed  List of Failed
>>-------------------------------------------------------------------------------
>>apr/finfo.t               17    1   5.88%  10
>>6 subtests skipped.
>>=====
>>
>>Nothing relevant appears in the error log.
>>
>>Versions: WinXP, MSVC6, perl-5.8.2, apache-2.0.48, mod_perl-cvs
>>    
>>
>
>I've just tried it too, with the latest mp2 cvs, and don't
>see this failure ... Does it still fail? The only difference
>between my system and yours is I'm using the perl-5.8.1
>sources of ActivePerl build 807 - could this make a
>difference?
>  
>
I just retested with the cvs version that I grabbed last Friday and 
found that it worked, but only once: thereafter it fails again!

More testing shows that if I "touch" the file that it is stat()'ing 
(t/htdocs/index.html) to give it file times of >1 hour ago then the 
offending test works, but any repeat tests immediately after that fail 
again:

C:\Temp\modperl-2.0>\cygwin\bin\touch 12151545 t/htdocs/index.html
C:\Temp\modperl-2.0>perl t/TEST -verbose apr/finfo.t
[OK]
C:\Temp\modperl-2.0>perl t/TEST -verbose apr/finfo.t
[Fails test 10]
C:\Temp\modperl-2.0>perl t/TEST -verbose apr/finfo.t
[Fails test 10]
C:\Temp\modperl-2.0>perl t/TEST -verbose apr/finfo.t
[Fails test 10]
...
C:\Temp\modperl-2.0>\cygwin\bin\touch 12151545 t/htdocs/index.html
C:\Temp\modperl-2.0>perl t/TEST -verbose apr/finfo.t
[OK]
C:\Temp\modperl-2.0>perl t/TEST -verbose apr/finfo.t
[Fails test 10]
C:\Temp\modperl-2.0>perl t/TEST -verbose apr/finfo.t
[Fails test 10]
C:\Temp\modperl-2.0>perl t/TEST -verbose apr/finfo.t
[Fails test 10]
...

Bizarre!  Do you observe this behaviour?  If not, then I'll give 
ActivePerl 807 a try myself.

I get the same thing happening with the latest cvs which I've just 
grabbed (with your patch for modperl_mgv.c).

An obvious "fix" is to utime() the file in question to set the file 
times to >1 hour ago:

=====
--- t/response/TestAPR/finfo.pm.orig    2003-12-01 19:16:51.000000000 +0000
+++ t/response/TestAPR/finfo.pm    2003-12-15 16:52:38.000161500 +0000
@@ -42,6 +42,10 @@
 
     my $file = Apache->server_root_relative(catfile qw(htdocs index.html));
 
+    # make the file times >1 hour ago so that the tests work on Win32 (!)
+    my $then = time - (61 * 60);
+    utime $then, $then, $file;
+
     # stat tests
     {
         # populate the finfo struct first
=====

This works for me, but it's very strange.  I wonder what the real 
problem is?

- Steve



------------------------------------------------
Radan Computational Ltd.

The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only.  If you have received this message in error or there are any problems, please notify the sender immediately.  The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden.  Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd.  The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email.


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


Re: [mp2] apr/finfo test 10 fails on Windows

Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Fri, 12 Dec 2003, Steve Hay wrote:

> I've just run the mp2 testsuite using the latest CVS version and got one
> test failure:
>
> =====
>  >perl t/TEST -verbose apr/finfo.t
> [...]
> # Running under perl version 5.008002 for MSWin32
> # Current time local: Fri Dec 12 17:36:14 2003
> # Current time GMT:   Fri Dec 12 17:36:14 2003
> # Using Test.pm version 1.24
> [...]
> # testing : $r->finfo->atime()
> # expected: 1071249888
> # received: 1071250580
> not ok 10
> [...]
> FAILED test 10
>         Failed 1/17 tests, 94.12% okay (less 6 skipped tests: 10 okay,
> 58.82%)
> Failed Test Stat Wstat Total Fail  Failed  List of Failed
> -------------------------------------------------------------------------------
> apr/finfo.t               17    1   5.88%  10
> 6 subtests skipped.
> =====
>
> Nothing relevant appears in the error log.
>
> Versions: WinXP, MSVC6, perl-5.8.2, apache-2.0.48, mod_perl-cvs

I've just tried it too, with the latest mp2 cvs, and don't
see this failure ... Does it still fail? The only difference
between my system and yours is I'm using the perl-5.8.1
sources of ActivePerl build 807 - could this make a
difference?

-- 
best regards,
randy

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