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