You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@perl.apache.org by Randy Kobes <ra...@theoryx5.uwinnipeg.ca> on 2006/05/31 06:34:24 UTC
[mp2] finfo->ctime on Win32
Hi Steve, and all,
With the svn mp2 sources on Win32, and with either
Apache/2.0 or Apache/2.2, I'm getting a couple of
failures on t/(apr|apr-ext)/finfo.t with the finfo->ctime
tests. The failures looked like
# testing : $finfo->ctime()
# expected: 1135891825
# received: 1135888225
and so differ by 3600. Steve, I know that you've
encountered this general type of problem before
(in the context of Win32::UTCFileTime, and related
to time zones and daylight savings time) - do you
see a similar failure? I'm thinking it might be an
idea to just skip the ctime tests on Win32, unless
someone knows what the root cause of the problem is.
Thanks.
--
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] finfo->ctime on Win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
On Tue, 6 Jun 2006, Steve Hay wrote:
> Steve Hay wrote:
>> Randy Kobes wrote:
>>> 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?
>>
>> The patch works OK for me (and, as you say, we don't need the utime()
>> call any more either.)
>
> Randy, I see that you applied your patch to change the file used in the
> finfo tests, but you didn't remove the utime() call. Was there any
> particular reason why not, or just an oversight?
>
> I can't see any point to keeping it now: the httpd.conf file should be
> up-to-date (i.e. in the same DST season), and if it isn't then the
> utime() call will only fix up the mtime, not the ctime, which is
> probably more confusing than helpful.
>
> With the attached patch, I currently have all tests successful.
Hi Steve,
That was an oversight - you're right that leaving it in
there is confusing. Thanks for the patch - this was
committed as revision 412118.
--
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] finfo->ctime on Win32
Posted by Steve Hay <st...@uk.radan.com>.
Steve Hay wrote:
> Randy Kobes wrote:
>> 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?
>
> The patch works OK for me (and, as you say, we don't need the utime()
> call any more either.)
Randy, I see that you applied your patch to change the file used in the
finfo tests, but you didn't remove the utime() call. Was there any
particular reason why not, or just an oversight?
I can't see any point to keeping it now: the httpd.conf file should be
up-to-date (i.e. in the same DST season), and if it isn't then the
utime() call will only fix up the mtime, not the ctime, which is
probably more confusing than helpful.
With the attached patch, I currently have all tests successful.
------------------------------------------------
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.
Re: [mp2] finfo->ctime on Win32
Posted by Steve Hay <st...@uk.radan.com>.
Randy Kobes wrote:
> 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?
The patch works OK for me (and, as you say, we don't need the utime()
call any more either.)
It might just be worth checking if there was any particular reason that
$file was __FILE__ first, though: in (much) earlier versions of mp2 it
used to be t/htdocs/index.html. Unless there was some specific reason
for that change then I think this patch is fine.
>
> ====================================================
>
> 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->{t_dir}, '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.
>
------------------------------------------------
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.
Re: [mp2] finfo->ctime on Win32
Posted by Randy Kobes <ra...@theoryx5.uwinnipeg.ca>.
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->{t_dir}, '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-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] finfo->ctime on Win32
Posted by Steve Hay <st...@uk.radan.com>.
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.
Re: [mp2] finfo->ctime on Win32
Posted by Geoffrey Young <ge...@modperlcookbook.org>.
> 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-unsubscribe@perl.apache.org
For additional commands, e-mail: dev-help@perl.apache.org
Re: [mp2] finfo->ctime on Win32
Posted by Steve Hay <st...@uk.radan.com>.
Steve Hay wrote:
> Randy Kobes wrote:
>> Hi Steve, and all,
>> With the svn mp2 sources on Win32, and with either
>> Apache/2.0 or Apache/2.2, I'm getting a couple of
>> failures on t/(apr|apr-ext)/finfo.t with the finfo->ctime
>> tests. The failures looked like
>> # testing : $finfo->ctime()
>> # expected: 1135891825
>> # received: 1135888225
>> and so differ by 3600. Steve, I know that you've
>> encountered this general type of problem before
>> (in the context of Win32::UTCFileTime, and related
>> to time zones and daylight savings time) - do you
>> see a similar failure? I'm thinking it might be an
>> idea to just skip the ctime tests on Win32, unless
>> someone knows what the root cause of the problem is.
>> Thanks.
>
> The problem that I've encountered before is where MS's CRT stat()
> function returns the wrong time (by one hour) when the file time
> (access, creation or modification) being retrieved lies in the opposite
> DST seasons to the current system time.
>
> That is why the finfo.pm tests do a utime() call on Win32.
[...]
> Are the file times on your finfo.pm being
> correctly reset by the utime() call?
Gah! That's it! I bet they aren't being set correctly, at least the
*ctime* isn't, because utime() only touches the atime and mtime!!!
You must have created that finfo.pm in the opposite DST season to your
current system time.
So the utime() call perhaps needs to be changed to something that
affects the ctime as well (e.g. copy the file, delete the original,
rename the copy back), but that could be tricky given that the file in
question is __FILE__ ;-)
Maybe test a different file instead?
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.
------------------------------------------------
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.
Re: [mp2] finfo->ctime on Win32
Posted by Steve Hay <st...@uk.radan.com>.
Randy Kobes wrote:
> Hi Steve, and all,
> With the svn mp2 sources on Win32, and with either
> Apache/2.0 or Apache/2.2, I'm getting a couple of
> failures on t/(apr|apr-ext)/finfo.t with the finfo->ctime
> tests. The failures looked like
> # testing : $finfo->ctime()
> # expected: 1135891825
> # received: 1135888225
> and so differ by 3600. Steve, I know that you've
> encountered this general type of problem before
> (in the context of Win32::UTCFileTime, and related
> to time zones and daylight savings time) - do you
> see a similar failure? I'm thinking it might be an
> idea to just skip the ctime tests on Win32, unless
> someone knows what the root cause of the problem is.
> Thanks.
The problem that I've encountered before is where MS's CRT stat()
function returns the wrong time (by one hour) when the file time
(access, creation or modification) being retrieved lies in the opposite
DST seasons to the current system time.
That is why the finfo.pm tests do a utime() call on Win32. I originally
had a problem with the mtime, but I haven't seen that problem recur see
we introduced that utime() call:
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=109957076131483&w=2
I once also had a failure with atime, which Geoffrey pointed out could
be due to the worrying noises that MSDN makes about the ftLastAccessTime
member in the structure populated by GetFileInformationByHandle() always
being set to midnight. We eventually decided that skipping the atime
test was best on Win32:
http://marc.theaimsgroup.com/?l=apache-modperl-dev&m=107158266508047&w=2
However, MSDN doesn't give the same warnings about ctime, so AFAICT it
should work:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/fileio/fs/by_handle_file_information_str.asp
What filesystem are you running these tests on? What timezone / DST
season is your system in? Are the file times on your finfo.pm being
correctly reset by the utime() call?
------------------------------------------------
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.