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/16 16:35:09 UTC
[PATCH] Re: [mp2] apr/finfo test 10 fails on Windows
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: [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