win32utils devel - Dec 2006 - Tweak to win32-eventlog

All,

I got a bug report from Greg Holmes where the description wasn''t being 
returned properly.  At the moment, if there''s no event associated with 
the event id, then the description is empty.

However, it turns out that there can still be associated information 
about the event.  So, I propose the following tweak to the 
get_description private method:

# If FormatMessage() returned 0, but va_list isn''t empty,
# then return the va_list instead.
if val == 0 && !va_list.empty?
    buf = va_list.join("\n")
end

Where ''val'' is the result of the FormatMessage() call. 
I''ve attached
the sample backup file he sent me to demonstrate the problem.  The patch 
above seems to work fine.

Please let me know if you have any issues with this approach.  If not, 
I''d like to get a release out this weekend.

Thanks,

Dan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: backup.evt
Type: application/octet-stream
Size: 4260 bytes
Desc: not available
Url :
http://rubyforge.org/pipermail/win32utils-devel/attachments/20061213/0afbaba7/attachment.obj

On 12/13/06, Daniel Berger <djberg96 at gmail.com>
wrote:
> All,
>
> I got a bug report from Greg Holmes where the description wasn''t
being
> returned properly.  At the moment, if there''s no event associated
with
> the event id, then the description is empty.
>
> However, it turns out that there can still be associated information
> about the event.  So, I propose the following tweak to the
> get_description private method:
>
> # If FormatMessage() returned 0, but va_list isn''t empty,
> # then return the va_list instead.
> if val == 0 && !va_list.empty?
>     buf = va_list.join("\n")
> end
>
> Where ''val'' is the result of the FormatMessage() call. 
I''ve attached
> the sample backup file he sent me to demonstrate the problem.  The patch
> above seems to work fine.
>
> Please let me know if you have any issues with this approach.  If not,
> I''d like to get a release out this weekend.
Actually, I''ve been looking over the Python evtlogutils stuff, and I
think a better approach is to allow people to get at the string
inserts independently of the full event log message as the Python
module does. So, I''m going to add the string_inserts member to the
EventLogStruct. Sound good?

I also realized that we should probably check the CategoryMessageFile
and ParameterMessageFile instead of only the EventMessageFile in the
get_description method.

Last but not least, I''m getting strange results for the attached
backup event log.  If you''ve got the .NET 2.0 runtime installed,
you''ll end up getting, ""The operation completed
successfully."
instead of what I would expect, i.e. nothing.  Suggestions welcome.

- Dan

Hi Dan,

It was great seeing you again at RubyConf Denver!

I gave the win32-eventlog 0.4.2 gem a try on my XP SP 2 system with
Ruby 1.8.5 (.NET 2.0 runtime installed), and I get two test failures:

C:\ruby\lib\ruby\gems\1.8\gems\win32-eventlog-0.4.2\test>ruby -v
ruby 1.8.5 (2006-08-25) [i386-mswin32]

C:\ruby\lib\ruby\gems\1.8\gems\win32-eventlog-0.4.2\test>ruby tc_eventlog.rb

Relax - this will take a few moments

Loaded suite tc_eventlog
Started
...................FF.....
Finished in 57.969 seconds.

  1) Failure:
test_seek_read(TC_EventLog) [tc_eventlog.rb:116]:
<11> expected but was
<0>.

  2) Failure:
test_seek_read_backwards(TC_EventLog) [tc_eventlog.rb:123]:
<10> expected but was
<0>.

26 tests, 5180 assertions, 2 failures, 0 errors

I tried debugging this a little. In the above 2 cases, after the
ReadEventLog call, GetLastError returns 87 ("The parameter is
incorrect").

I played around with calls that failed and calls that succeeded, and
finally got these two test cases:

This one works:
      flags = EventLog::SEQUENTIAL_READ | EventLog::FORWARDS_READ
      @records = EventLog.read(nil, nil, flags)

And this one fails:
      flags = EventLog::SEEK_READ | EventLog::FORWARDS_READ
      @records = EventLog.read(nil, nil, flags)

In the actual call to ReadEventLog in eventlog.rb line 460, the only
difference is the value of flags, which is 5 when it works, and 6 when
it fails.  I checked the Win32 documentation, and everything seems to
be fine, and it looks like both calls should succeed.

I''m perfectly willing to help debug this, if anyone can suggest what I
should try next.  I guess one next step would be to try making this
same call from C or C++, but I didn''t try that yet.

I also tried on Win2K SP4, Ruby 1.8.2, and that works fine.

Thanks,

Wayne


On 12/16/06, Daniel Berger <djberg96 at gmail.com>
wrote:
> On 12/13/06, Daniel Berger <djberg96 at gmail.com> wrote:
> > All,
> >
> > I got a bug report from Greg Holmes where the description
wasn''t being
> > returned properly.  At the moment, if there''s no event
associated with
> > the event id, then the description is empty.
> >
> > However, it turns out that there can still be associated information
> > about the event.  So, I propose the following tweak to the
> > get_description private method:
> >
> > # If FormatMessage() returned 0, but va_list isn''t empty,
> > # then return the va_list instead.
> > if val == 0 && !va_list.empty?
> >     buf = va_list.join("\n")
> > end
> >
> > Where ''val'' is the result of the FormatMessage()
call.  I''ve attached
> > the sample backup file he sent me to demonstrate the problem.  The
patch
> > above seems to work fine.
> >
> > Please let me know if you have any issues with this approach.  If not,
> > I''d like to get a release out this weekend.
>
> Actually, I''ve been looking over the Python evtlogutils stuff, and
I
> think a better approach is to allow people to get at the string
> inserts independently of the full event log message as the Python
> module does. So, I''m going to add the string_inserts member to the
> EventLogStruct. Sound good?
>
> I also realized that we should probably check the CategoryMessageFile
> and ParameterMessageFile instead of only the EventMessageFile in the
> get_description method.
>
> Last but not least, I''m getting strange results for the attached
> backup event log.  If you''ve got the .NET 2.0 runtime installed,
> you''ll end up getting, ""The operation completed
successfully."
> instead of what I would expect, i.e. nothing.  Suggestions welcome.
>
> - Dan
> _______________________________________________
> win32utils-devel mailing list
> win32utils-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/win32utils-devel
>

Wayne Vucenic wrote:
> Hi Dan,
> 
> It was great seeing you again at RubyConf Denver!
Likewise.
> I gave the win32-eventlog 0.4.2 gem a try on my XP SP 2 system with
> Ruby 1.8.5 (.NET 2.0 runtime installed), and I get two test failures:
> 
> C:\ruby\lib\ruby\gems\1.8\gems\win32-eventlog-0.4.2\test>ruby -v
> ruby 1.8.5 (2006-08-25) [i386-mswin32]
> 
> C:\ruby\lib\ruby\gems\1.8\gems\win32-eventlog-0.4.2\test>ruby
tc_eventlog.rb
> 
> Relax - this will take a few moments
> 
> Loaded suite tc_eventlog
> Started
> ...................FF.....
> Finished in 57.969 seconds.
> 
>   1) Failure:
> test_seek_read(TC_EventLog) [tc_eventlog.rb:116]:
> <11> expected but was
> <0>.
> 
>   2) Failure:
> test_seek_read_backwards(TC_EventLog) [tc_eventlog.rb:123]:
> <10> expected but was
> <0>.
> 
> 26 tests, 5180 assertions, 2 failures, 0 errors
> 
> I tried debugging this a little. In the above 2 cases, after the
> ReadEventLog call, GetLastError returns 87 ("The parameter is
> incorrect").
> 
> I played around with calls that failed and calls that succeeded, and
> finally got these two test cases:
> 
> This one works:
>       flags = EventLog::SEQUENTIAL_READ | EventLog::FORWARDS_READ
>       @records = EventLog.read(nil, nil, flags)
> 
> And this one fails:
>       flags = EventLog::SEEK_READ | EventLog::FORWARDS_READ
>       @records = EventLog.read(nil, nil, flags)
> 
> In the actual call to ReadEventLog in eventlog.rb line 460, the only
> difference is the value of flags, which is 5 when it works, and 6 when
> it fails.  I checked the Win32 documentation, and everything seems to
> be fine, and it looks like both calls should succeed.
> 
> I''m perfectly willing to help debug this, if anyone can suggest
what I
> should try next.  I guess one next step would be to try making this
> same call from C or C++, but I didn''t try that yet.
> 
> I also tried on Win2K SP4, Ruby 1.8.2, and that works fine.
> 
> Thanks,
> 
> Wayne
These tests pass on my system.  These tests are not especially robust. 
If the event log happens to have 10 or fewer event records, they will 
fail, so I''m guessing that''s what happened here.  I suppose I
should
check the length first, or just issue a failure message that warns about 
  the possible reasons for a failure.

Regards,

Dan

> If the event log happens to have 10 or fewer event records, they will
> fail, so I''m guessing that''s what happened here.
I thought about that, which is why I tried the two test cases which
don''t pass the 10 parameter.   And in any event (no pun intended), my
Application event log has 2500 event records (as reported by Windows''
Event Viewer) and my System event log has 1900 event records.
> These tests pass on my system.
Which OS are you using?  They work for me on Win2K.  They fail on XP
SP2 and they fail in a different way on NT4 SP6 (but I''m assuming you
don''t support NT4, which is quite reasonable)

You are quite correct that if the event log has 10 or less records,
the same tests fail as failed in my case.  But I''m pretty sure these
are two different situations that simply happen to produce the same
output.

I cleared the Application event log on my Win2K system, where these
tests used to all pass, and re-ran the tests:

C:\ruby\lib\ruby\gems\1.8\gems\win32-eventlog-0.4.2\test>ruby tc_eventlog.rb

Relax - this will take a few moments

Loaded suite tc_eventlog
Started
...................FF.....
Finished in 0.203 seconds.

  1) Failure:
test_seek_read(TC_EventLog) [tc_eventlog.rb:116]:
<11> expected but was
<0>.

  2) Failure:
test_seek_read_backwards(TC_EventLog) [tc_eventlog.rb:123]:
<10> expected but was
<0>.

26 tests, 74 assertions, 2 failures, 0 errors

But the difference is that in this case the ReadEventLog call is
setting GetLastError to 38 (end of file), which makes sense.  In the
error I''m seeing (with an application eventlog with 2500 records),
ReadEventLog sets GetLastError to 87.  To demonstrate this, I made a
change to eventlog.rb, adding one line after line 510:

            buf = 0.chr * BUFFER_SIZE
            read = [0].pack(''L'')
         end

         print "GetLastError returns ", GetLastError(), "\n"
# ADDED LINE

         block_given? ? nil : array
      end

Rerunning the test on Win2K (with empty Application log) with the
changed eventlog.rb:

C:\ruby\lib\ruby\gems\1.8\gems\win32-eventlog-0.4.2\test>ruby tc_eventlog.rb

Relax - this will take a few moments

Loaded suite tc_eventlog
Started
.GetLastError returns 38
GetLastError returns 38
GetLastError returns 38
GetLastError returns 38
GetLastError returns 38
..GetLastError returns 38
...........GetLastError returns 38
.GetLastError returns 38
GetLastError returns 38
GetLastError returns 38
....GetLastError returns 38
FGetLastError returns 38
F.....
Finished in 0.563 seconds.

  1) Failure:
test_seek_read(TC_EventLog) [tc_eventlog.rb:116]:
<11> expected but was
<0>.

  2) Failure:
test_seek_read_backwards(TC_EventLog) [tc_eventlog.rb:123]:
<10> expected but was
<0>.

26 tests, 74 assertions, 2 failures, 0 errors

However, when I use the same eventlog.rb on my XP system that''s having
the problem:

C:\ruby\lib\ruby\gems\1.8\gems\win32-eventlog-0.4.2\test>ruby tc_eventlog.rb

Relax - this will take a few moments

Loaded suite tc_eventlog
Started
...GetLastError returns 38
................GetLastError returns 87
FGetLastError returns 87
F.....
Finished in 61.25 seconds.

  1) Failure:
test_seek_read(TC_EventLog) [tc_eventlog.rb:116]:
<11> expected but was
<0>.

  2) Failure:
test_seek_read_backwards(TC_EventLog) [tc_eventlog.rb:123]:
<10> expected but was
<0>.

26 tests, 5178 assertions, 2 failures, 0 errors

So on Win2K with an empty Application log, these two tests get 0
records because the ReadEventLog call returns "end of file", which is
correct.  On my XP system with a full Application log, these two tests
get 0 records because the ReadEventLog call returns error 87
"parameter is incorrect", which doesn''t seem right.

Perhaps eventlog.rb should be changed to throw an exception if we get
any GetLastError() other than 38 (or 0) ?

This particular problem isn''t getting in my way at the moment, so
I''m
not suggesting that we need to figure out what''s happening or do
anything about it.  But I did want to report it, just in case.

Thanks,

Wayne

On 12/16/06, Daniel Berger <djberg96 at gmail.com>
wrote:
> Wayne Vucenic wrote:
> > Hi Dan,
> >
> > It was great seeing you again at RubyConf Denver!
>
> Likewise.
>
> > I gave the win32-eventlog 0.4.2 gem a try on my XP SP 2 system with
> > Ruby 1.8.5 (.NET 2.0 runtime installed), and I get two test failures:
> >
> > C:\ruby\lib\ruby\gems\1.8\gems\win32-eventlog-0.4.2\test>ruby -v
> > ruby 1.8.5 (2006-08-25) [i386-mswin32]
> >
> > C:\ruby\lib\ruby\gems\1.8\gems\win32-eventlog-0.4.2\test>ruby
tc_eventlog.rb
> >
> > Relax - this will take a few moments
> >
> > Loaded suite tc_eventlog
> > Started
> > ...................FF.....
> > Finished in 57.969 seconds.
> >
> >   1) Failure:
> > test_seek_read(TC_EventLog) [tc_eventlog.rb:116]:
> > <11> expected but was
> > <0>.
> >
> >   2) Failure:
> > test_seek_read_backwards(TC_EventLog) [tc_eventlog.rb:123]:
> > <10> expected but was
> > <0>.
> >
> > 26 tests, 5180 assertions, 2 failures, 0 errors
> >
> > I tried debugging this a little. In the above 2 cases, after the
> > ReadEventLog call, GetLastError returns 87 ("The parameter is
> > incorrect").
> >
> > I played around with calls that failed and calls that succeeded, and
> > finally got these two test cases:
> >
> > This one works:
> >       flags = EventLog::SEQUENTIAL_READ | EventLog::FORWARDS_READ
> >       @records = EventLog.read(nil, nil, flags)
> >
> > And this one fails:
> >       flags = EventLog::SEEK_READ | EventLog::FORWARDS_READ
> >       @records = EventLog.read(nil, nil, flags)
> >
> > In the actual call to ReadEventLog in eventlog.rb line 460, the only
> > difference is the value of flags, which is 5 when it works, and 6 when
> > it fails.  I checked the Win32 documentation, and everything seems to
> > be fine, and it looks like both calls should succeed.
> >
> > I''m perfectly willing to help debug this, if anyone can
suggest what I
> > should try next.  I guess one next step would be to try making this
> > same call from C or C++, but I didn''t try that yet.
> >
> > I also tried on Win2K SP4, Ruby 1.8.2, and that works fine.
> >
> > Thanks,
> >
> > Wayne
>
> These tests pass on my system.  These tests are not especially robust.
> If the event log happens to have 10 or fewer event records, they will
> fail, so I''m guessing that''s what happened here.  I
suppose I should
> check the length first, or just issue a failure message that warns about
>  the possible reasons for a failure.
>
> Regards,
>
> Dan
> _______________________________________________
> win32utils-devel mailing list
> win32utils-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/win32utils-devel
>

Wayne Vucenic wrote:
>> If the event log happens to have 10 or fewer event records, they will
>> fail, so I''m guessing that''s what happened here.
> 
> I thought about that, which is why I tried the two test cases which
> don''t pass the 10 parameter.   And in any event (no pun intended),
my
> Application event log has 2500 event records (as reported by
Windows''
> Event Viewer) and my System event log has 1900 event records.
> 
>> These tests pass on my system.
> 
> Which OS are you using?  They work for me on Win2K.  They fail on XP
> SP2 and they fail in a different way on NT4 SP6 (but I''m assuming
you
> don''t support NT4, which is quite reasonable)
Windows XP SP2.
> You are quite correct that if the event log has 10 or less records,
> the same tests fail as failed in my case.  But I''m pretty sure
these
> are two different situations that simply happen to produce the same
> output.
<snip>

Please do me a favor and backup the event log that''s causing you 
problems and send it to me offlist.  I have a couple of theories - could 
be a record number issue, could be a buffer issue - but I''m not
positive.

Thanks,

Dan

[I meant to CC this but accidentally left the attachment on so it got 
rejected.  Anyway, here''s what I sent to Greg].

Greg,

I think I''ve solved it.  It seems to be the FORMAT_MESSAGE_FROM_SYSTEM 
flag.  One poster claims that it doesn''t actually work properly when 
used with FORMAT_MESSAGE_FROM_HMODULE.

I''m not sure.  From the docs for FORMAT_MESSAGE_FROM_SYSTEM:

"If this flag is specified, an application can pass the result of the 
GetLastError function to retrieve the message text for a system-defined 
error."

I think that''s what it''s doing, although I would think the app
would
only set that if there was an -actual failure-.  That''s arguably a bug 
in the .NET runtime.  But whatever.

What that tells me is that the Windows Event Viewer does *not* check for 
a system message.  I guess now I have to decided if I should just remove 
the FORMAT_MESSAGE_FROM_SYSTEM flag (which fixes your problem, btw).  I 
probably will, since it''s a lot easier than dealing with the confusion 
otherwise generated. :)

In any case, keep your eyes open for a new release soon. :)

Many thanks for the bug report.  This was a tough one.

Regards,

Dan

Wayne Vucenic wrote:
>> If the event log happens to have 10 or fewer event records, they will
>> fail, so I''m guessing that''s what happened here.
> 
> I thought about that, which is why I tried the two test cases which
> don''t pass the 10 parameter.   And in any event (no pun intended),
my
> Application event log has 2500 event records (as reported by
Windows''
> Event Viewer) and my System event log has 1900 event records.
<snip>

Oh, I remember now.  The offset parameter refers to a record number that 
actually exists.  The ReadEventLog function isn''t smart enough to take
a
0 and understand that you mean to start at the oldest record.

With the backup log that you sent me offlist, this snippet worked fine:

flags = EventLog::SEEK_READ | EventLog::FORWARDS_READ
log = EventLog.open_backup(''AppEventLogForDan.evt'')
log.read(flags, log.oldest_record_number).each{ |l|
    p l
}
log.close

The tests you mentioned earlier fail because the oldest record number 
may not be the last record number - the numbers eventually get re-used. 
  So, the only way to make them work is to use 
EventLog#oldest_record_number as the offset.  I don''t like using one 
method as part of another''s test, but I see no choice here. 
I''ll update
the tests.

I should have release 0.4.3 out today.

Regards,

Dan

Hi Dan,

Congratulations!  Thanks for figuring out what''s going on here.

Take care,

Wayne


On 12/18/06, Daniel Berger <djberg96 at gmail.com>
wrote:
>
> Wayne Vucenic wrote:
> >> If the event log happens to have 10 or fewer event records, they
will
> >> fail, so I''m guessing that''s what happened here.
> >
> > I thought about that, which is why I tried the two test cases which
> > don''t pass the 10 parameter.   And in any event (no pun
intended), my
> > Application event log has 2500 event records (as reported by
Windows''
> > Event Viewer) and my System event log has 1900 event records.
>
> <snip>
>
> Oh, I remember now.  The offset parameter refers to a record number that
> actually exists.  The ReadEventLog function isn''t smart enough to
take a
> 0 and understand that you mean to start at the oldest record.
>
> With the backup log that you sent me offlist, this snippet worked fine:
>
> flags = EventLog::SEEK_READ | EventLog::FORWARDS_READ
> log = EventLog.open_backup(''AppEventLogForDan.evt'')
> log.read(flags, log.oldest_record_number).each{ |l|
>    p l
> }
> log.close
>
> The tests you mentioned earlier fail because the oldest record number
> may not be the last record number - the numbers eventually get re-used.
> So, the only way to make them work is to use
> EventLog#oldest_record_number as the offset.  I don''t like using
one
> method as part of another''s test, but I see no choice here. 
I''ll update
> the tests.
>
> I should have release 0.4.3 out today.
>
> Regards,
>
> Dan
> _______________________________________________
> win32utils-devel mailing list
> win32utils-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/win32utils-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/win32utils-devel/attachments/20061218/31850deb/attachment.html

Hi Dan,
> I should have release 0.4.3 out today.
I tried the 0.4.3 gem on my XP system that was having the problem before:

C:\ruby\lib\ruby\gems\1.8\gems\win32-eventlog-0.4.3\test>ruby tc_eventlog.rb

Relax - this will take a few moments

Loaded suite tc_eventlog
Started
...................FF....F
Finished in 317.016 seconds.

  1) Failure:
test_seek_read(TC_EventLog) [tc_eventlog.rb:116]:
<11> expected but was
<0>.

  2) Failure:
test_seek_read_backwards(TC_EventLog) [tc_eventlog.rb:123]:
<10> expected but was
<0>.

  3) Failure:
test_version(TC_EventLog) [tc_eventlog.rb:29]:
<"0.4.2"> expected but was
<"0.4.3">.

26 tests, 5206 assertions, 3 failures, 0 errors

It looks like something didn''t get updated for 0.4.3.  I notice that
the tc_eventlog.rb
file is identical between 0.4.2 and 0.4.3.

I then tried it on my Win2K system that used to work, and I get:

C:\ruby\lib\ruby\gems\1.8\gems\win32-eventlog-0.4.3\test>ruby tc_eventlog.rb

Relax - this will take a few moments

Loaded suite tc_eventlog
Started
...................FF....F
Finished in 0.609 seconds.

  1) Failure:
test_seek_read(TC_EventLog) [tc_eventlog.rb:116]:
<11> expected but was
<0>.

  2) Failure:
test_seek_read_backwards(TC_EventLog) [tc_eventlog.rb:123]:
<10> expected but was
<0>.

  3) Failure:
test_version(TC_EventLog) [tc_eventlog.rb:29]:
<"0.4.2"> expected but was
<"0.4.3">.

26 tests, 82 assertions, 3 failures, 0 errors

It''s odd that I''m now seeing the two failures on this system,
as I didn''t
see them before.

Thanks,

Wayne

Wayne Vucenic wrote:
> Hi Dan,
> 
>> I should have release 0.4.3 out today.
> 
> I tried the 0.4.3 gem on my XP system that was having the problem before:
> 
> C:\ruby\lib\ruby\gems\1.8\gems\win32-eventlog-0.4.3\test>ruby
tc_eventlog.rb
> 
> Relax - this will take a few moments
> 
> Loaded suite tc_eventlog
> Started
> ...................FF....F
> Finished in 317.016 seconds.
> 
>   1) Failure:
> test_seek_read(TC_EventLog) [tc_eventlog.rb:116]:
> <11> expected but was
> <0>.
> 
>   2) Failure:
> test_seek_read_backwards(TC_EventLog) [tc_eventlog.rb:123]:
> <10> expected but was
> <0>.
> 
>   3) Failure:
> test_version(TC_EventLog) [tc_eventlog.rb:29]:
> <"0.4.2"> expected but was
> <"0.4.3">.
> 
> 26 tests, 5206 assertions, 3 failures, 0 errors
> 
> It looks like something didn''t get updated for 0.4.3.  I notice
that
> the tc_eventlog.rb
> file is identical between 0.4.2 and 0.4.3.
> 
> I then tried it on my Win2K system that used to work, and I get:
> 
> C:\ruby\lib\ruby\gems\1.8\gems\win32-eventlog-0.4.3\test>ruby
tc_eventlog.rb
> 
> Relax - this will take a few moments
> 
> Loaded suite tc_eventlog
> Started
> ...................FF....F
> Finished in 0.609 seconds.
> 
>   1) Failure:
> test_seek_read(TC_EventLog) [tc_eventlog.rb:116]:
> <11> expected but was
> <0>.
> 
>   2) Failure:
> test_seek_read_backwards(TC_EventLog) [tc_eventlog.rb:123]:
> <10> expected but was
> <0>.
> 
>   3) Failure:
> test_version(TC_EventLog) [tc_eventlog.rb:29]:
> <"0.4.2"> expected but was
> <"0.4.3">.
> 
> 26 tests, 82 assertions, 3 failures, 0 errors
> 
> It''s odd that I''m now seeing the two failures on this
system, as I didn''t
> see them before.
Yeah, I forgot to update the test file.  I wouldn''t worry about the 
failures.  They''re likely failing for the same reason.

I''m off to Florida tomorrow, so this will have to wait until next year.

Regards,

Dan

Sounds good.  Have a great time in Florida!

See you next year,

Wayne

On 12/20/06, Daniel Berger <djberg96 at gmail.com>
wrote:
> Wayne Vucenic wrote:
> > Hi Dan,
> >
> >> I should have release 0.4.3 out today.
> >
> > I tried the 0.4.3 gem on my XP system that was having the problem
before:
> >
> > C:\ruby\lib\ruby\gems\1.8\gems\win32-eventlog-0.4.3\test>ruby
tc_eventlog.rb
> >
> > Relax - this will take a few moments
> >
> > Loaded suite tc_eventlog
> > Started
> > ...................FF....F
> > Finished in 317.016 seconds.
> >
> >   1) Failure:
> > test_seek_read(TC_EventLog) [tc_eventlog.rb:116]:
> > <11> expected but was
> > <0>.
> >
> >   2) Failure:
> > test_seek_read_backwards(TC_EventLog) [tc_eventlog.rb:123]:
> > <10> expected but was
> > <0>.
> >
> >   3) Failure:
> > test_version(TC_EventLog) [tc_eventlog.rb:29]:
> > <"0.4.2"> expected but was
> > <"0.4.3">.
> >
> > 26 tests, 5206 assertions, 3 failures, 0 errors
> >
> > It looks like something didn''t get updated for 0.4.3.  I
notice that
> > the tc_eventlog.rb
> > file is identical between 0.4.2 and 0.4.3.
> >
> > I then tried it on my Win2K system that used to work, and I get:
> >
> > C:\ruby\lib\ruby\gems\1.8\gems\win32-eventlog-0.4.3\test>ruby
tc_eventlog.rb
> >
> > Relax - this will take a few moments
> >
> > Loaded suite tc_eventlog
> > Started
> > ...................FF....F
> > Finished in 0.609 seconds.
> >
> >   1) Failure:
> > test_seek_read(TC_EventLog) [tc_eventlog.rb:116]:
> > <11> expected but was
> > <0>.
> >
> >   2) Failure:
> > test_seek_read_backwards(TC_EventLog) [tc_eventlog.rb:123]:
> > <10> expected but was
> > <0>.
> >
> >   3) Failure:
> > test_version(TC_EventLog) [tc_eventlog.rb:29]:
> > <"0.4.2"> expected but was
> > <"0.4.3">.
> >
> > 26 tests, 82 assertions, 3 failures, 0 errors
> >
> > It''s odd that I''m now seeing the two failures on
this system, as I didn''t
> > see them before.
>
> Yeah, I forgot to update the test file.  I wouldn''t worry about
the
> failures.  They''re likely failing for the same reason.
>
> I''m off to Florida tomorrow, so this will have to wait until next
year.
>
> Regards,
>
> Dan
> _______________________________________________
> win32utils-devel mailing list
> win32utils-devel at rubyforge.org
> http://rubyforge.org/mailman/listinfo/win32utils-devel
>