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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
