finfo->ctime on Win32

> Or is it safe to just ignore the problem?  Any real
users out there will
> presumably have a ctime that matches the current system
time, because
> they'll probably have extracted the mod_perl archive
only just prior to
> building & testing it.
> 
> Otherwise I'm happy for the test to be skipped, so
long as there is a
> brief comment explaining the reason.

my own thought is this...

if we have verified that perl is reporting the correct
answer (we've
looked at the file on the filesystem and know perl gets it
right
according to us humans) then the fix really should be in APR
- APR is
supposed to exist so we can forget about these
cross-platform issues and
focus on the "real" stuff.

as these finfo tests have shown all along, perl seems far
better at
being cross-platform than APR when it comes to finfo foo. 
and that
being the case, I don't see why we should jump successive
hurdles just
to prove that APR can't get things straight - this is a
straight API
we're supporting, without much in the way of intervention
(at least last
time I checked) so I don't see why we should be saddled
with the burned
of decyphering whatever quirks APR has in store for us...

so, I guess I'd suggest skipping the known bad finfo tests
on win32 with
a nice, clear message like 'finfo() is known to be very
quirky on win32
- use at your own risk'

for us developers, it might be nice to run the tests if
mod_perl is
compiled in maintainer mode so we can keep an eye on things
in case APR
gets just a bit better...

--Geoff

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeperl.apache.org
For additional commands, e-mail: dev-helpperl.apache.org

Geoffrey Young wrote:
>> Or is it safe to just ignore the problem?  Any real
users out there will
>> presumably have a ctime that matches the current
system time, because
>> they'll probably have extracted the mod_perl
archive only just prior to
>> building & testing it.
>>
>> Otherwise I'm happy for the test to be skipped, so
long as there is a
>> brief comment explaining the reason.
> 
> my own thought is this...
> 
> if we have verified that perl is reporting the correct
answer (we've
> looked at the file on the filesystem and know perl gets
it right
> according to us humans) then the fix really should be
in APR - APR is
> supposed to exist so we can forget about these
cross-platform issues and
> focus on the "real" stuff.

Unfortunately, Perl arguably doesn't get it right, which is
the reason 
for the existence of my Win32::UTCFileTime module 

There is a difficulty in deciding what is
"right", though.  The real 
problem is MS's crap CRT library: its stat() function
returns 
definitively wrong file times across DST season boundaries,
which leaves 
anything wrapping that stat() function with a dilemma:

- Should the wrapper try to be portable, ironing out the
idiosyncracies 
of the various systems on which it is built, so as to always
yield the 
same answer?  (This is understandably the approach that APR
has taken, 
that being largely the point of it.)

- Or should the wrapper be a thinner, less interventionist
layer that 
seeks only to expose the underlying system behaviour to some
new 
interface?  (This is the approach that Perl has taken,
simply exposing 
the CRT library function, with all its quirks and foibles,
to Perl.)

So just don't go waiting around for APR to be
"fixed", because I doubt 
very much that its authors consider it to be broken.


------------------------------------------------
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.

On Wed, 31 May 2006, Steve Hay wrote:

> Unfortunately, Perl arguably doesn't get it right,
which is the reason for 
> the existence of my Win32::UTCFileTime module 
> There is a difficulty in deciding what is
"right", though.  The real problem 
> is MS's crap CRT library: its stat() function returns
definitively wrong file 
> times across DST season boundaries, which leaves
anything wrapping that 
> stat() function with a dilemma:
> - Should the wrapper try to be portable, ironing out
the idiosyncracies of 
> the various systems on which it is built, so as to
always yield the same 
> answer?  (This is understandably the approach that APR
has taken, that being 
> largely the point of it.)
> - Or should the wrapper be a thinner, less
interventionist layer that seeks 
> only to expose the underlying system behaviour to some
new interface?  (This 
> is the approach that Perl has taken, simply exposing
the CRT library 
> function, with all its quirks and foibles, to Perl.)
> So just don't go waiting around for APR to be
"fixed", because I doubt very 
> much that its authors consider it to be broken.

Thanks very much for the explanation, Steve - that makes
sense. So as was mentioned earlier, this problem probably
won't be encountered by the majority of Win32 users,
who will be unpacking a CPAN distribution. It is
annoying for svn users though who may encounter this
problem - would the following patch be OK, which uses
the generated httpd.conf as the file?

====================================================

Index: finfo.pm
============================================================
=======
--- finfo.pm	(revision 410430)
+++ finfo.pm	(working copy)
 -30,7
+30,11 

  sub test {

-    my $file = __FILE__;
+    # for the file to be tested, use the httpd.conf 
generated
+    # by testing, so that it has a ctime that won't 
(usually)
+    # encounter a bug in Win32's stat() function for files

that
+    # span across DST season boundaries.
+    my $file = catfile Apache::Test::vars->,
'conf', 
'httpd.conf';

      # On Win32, touch the file to ensure it is in the same

Daylight Saving
      # Time season as the current time to workaround a bug 
in Win32's stat()

===========================================================

With this patch, there's no need (for me) to have the

     if (WIN32) {
         my $now = time;
         utime $now, $now, $file;
     }

immediately following this chunk, as using httpd.conf
addresses the same problem as this does.

-- 
best regards,
Randy

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribeperl.apache.org
For additional commands, e-mail: dev-helpperl.apache.org