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