Path: utzoo!attcan!uunet!lll-winken!csd4.milw.wisc.edu!leah!rpi!crdgw1!ge-dab!peora!tarpit!rd
From: rd@tarpit.uucp (Bob Thrush)
Newsgroups: comp.unix.microport
Subject: Re: another Micorport bug with C news
Message-ID: <1989Jul20.033022.5834@tarpit.uucp>
Date: 20 Jul 89 03:30:22 GMT
References: <1989Jul13.022941.3573@intacc.uucp> <1989Jul14.140318.4987@tmsoft.uucp> <116084@sun.Eng.Sun.COM>
Reply-To: rd@tarpit.UUCP (Bob Thrush)
Organization: Automation Intelligence,Inc; Orlando,FL
Lines: 21

In article <116084@sun.Eng.Sun.COM> plocher@sun.UUCP (John Plocher) writes:
>In article <1989Jul14.140318.4987@tmsoft.uucp> mason@tmsoft.UUCP (Dave Mason) writes:
>>In article <1989Jul13.022941.3573@intacc.uucp> mann@intacc.UUCP (Jeff Mann) writes:
>>> [ about ] some  weird action from relaynews.
>>Actually they don't fail, they just all start at the same place in the
>>file, as I remember the problem, so only the last remains in the file.
>The problem is a generic System Vr2 bug in many/most Vr2 systems.  I extracted
>the following from Microport's bug database:
>Bug 404 Rel 1.36 priority 3:
>Using fprintf to write to a file opened in "r+" mode will cause data written
>with fprintf() to be lost if fseek()s are done also.

  Sounds pretty dreadful.  I'm surprised this is the first report of
such a problem.  Am I just running through the raindrops with my C News 
installation under V/AT 2.4?  I (think) it has been properly handling 
an incoming feed and several outbound feeds with about 7 days of 
active (comp.) articles.  However, I'm beginning to wonder...

  I used the large model (no optimization).   Were the problems associated
with the small model?  Or was it corrected in 2.4 (Jeff Mann's original
report mentioned 2.3)?