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.