mann@intacc.uucp (Jeff Mann) (07/13/89)
I'm not sure how far this problem goes, but on this System V/AT rel 2.3, fseek(3) causes some weird action from relaynews. It seems that when working with a file which has been opened for update (read/write), performing an fseek after any writes causes subsequent writes to fail. I believe that this is a bug in the Microport software, but whether it is in fseek, or somewhere else, I don't know. In relay/history.c, in the history() function, the fseek() causes the subsequent fprintf of the history line to fail if the history file had already been opened and written to. This means you will get many articles installed (relaynews doesn't complain when it happens) without history entries, and they can't be expired (use mkhist to find them). My workaround is to move this fseek from where it is to right after the fopenwclex in openhist(), and to rely on the fact that the file pointer will be left at EOF after any writes. However, gethistory() also calls fseek() when it needs to get a history line. The only place that gethistory() is called is from control.c when cancelling an article. I changed gethistory() to close the history file after doing so. (Oh yeah, gethistory is also used in the ihave/sendme stuff, but I haven't looked at how this would affect it.) I think this will work, but I haven't really tested it. I'd appreciate any better ideas... -- | Jeff Mann - Inter/Access, Toronto ...uunet!mnetor!intacc!mann | | "A picture is worth 256 thousand words" {utzoo, utgpu}!chp!intacc!mann |
mason@tmsoft.uucp (Dave Mason) (07/14/89)
In article <1989Jul13.022941.3573@intacc.uucp> mann@intacc.UUCP (Jeff Mann) writes: >I'm not sure how far this problem goes, but on this System V/AT rel 2.3, >fseek(3) causes some weird action from relaynews. It seems that when >working with a file which has been opened for update (read/write), >performing an fseek after any writes causes subsequent writes to fail. 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. >I believe that this is a bug in the Microport software, but whether it >is in fseek, or somewhere else, I don't know. I have been running an earlier version of Cnews for just under a year. I had the same problem on a System Vr2 NS32000 box. I didn't figure out the exact source of the bug (it is some interaction between fseek and fprintf), but I changed that code to do an sprintf followed by a fwrite, and the problem was solved (only took 10 frustrating hours to figure out what was going wrong & fix it!) I mentioned this to Geoff in January, but he was reluctant to work around buggy stdio implementations, and didn't want to have a limited string size that the sprint solution implies (though that too could be worked around). I had hoped that the partial stdio package that comes with the current release would solve this problem, but I haven't had the time to start installing the new release yet. Did you try using the supplied stdio package rather than the one from your supplier? ../Dave
karl@ddsw1.MCS.COM (Karl Denninger) (07/17/89)
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: >>I'm not sure how far this problem goes, but on this System V/AT rel 2.3, >>fseek(3) causes some weird action from relaynews. It seems that when >>working with a file which has been opened for update (read/write), >>performing an fseek after any writes causes subsequent writes to fail. Try adding this after EACH write (fprintf, fputs, etc) call: fp->_flag |= _IOWRT; ("fp" is your file pointer) This bug is in most System V STDIO's before SVR3, and may even be in there as well. It is NOT present in Xenix or BSD stdio's. The symptom is that a write made to a file open for update will not show up in the file, even if you follow the rules and "seek" before a write is done after a read. This one was VERY frustrating to us, but we finally found and squashed the problem (I was about to toss stdio entirely from one of our packages at one point due to this one). -- Karl Denninger (karl@ddsw1.MCS.COM, <well-connected>!ddsw1!karl) Public Access Data Line: [+1 312 566-8911], Voice: [+1 312 566-8910] Macro Computer Solutions, Inc. "Quality Solutions at a Fair Price"
plocher%sally@Sun.COM (John Plocher) (07/18/89)
Followups to comp.unix.microport 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: >>I'm not sure how far this problem goes, but on this System V/AT rel 2.3, >>fseek(3) causes some weird action from relaynews. It seems that when >>working with a file which has been opened for update (read/write), >>performing an fseek after any writes causes subsequent writes to fail. > >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. Reason: The code in the stdio library provided with Systen Vr2 incorrectly modifies the _flag member of the FILE * structure when writing to a "r+" stream. Work Around: Set the _IOWRT flag by hand after each fprintf(): { FILE *fp; ... fprintf(fp, "format", args); fp->_flag|=_IOWRT ... } -John Plocher
rd@tarpit.uucp (Bob Thrush) (07/20/89)
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)?
plocher%sally@Sun.COM (John Plocher) (07/22/89)
>>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. Since many (most - I hope) have upgraded to the 2.4 SDS I'm not supprised that this is the first reported problem - it was fixed in the 2.4 version of the Software Development Set (which is a different package than the 2.4 version of the Runtime system!) -John Plocher