Xref: utzoo comp.unix.microport:3567 news.software.b:2539
Path: utzoo!yunexus!intacc!mann
From: mann@intacc.uucp (Jeff Mann)
Newsgroups: comp.unix.microport,news.software.b
Subject: another Micorport bug with C news
Keywords: C news fseek history.c
Message-ID: <1989Jul13.022941.3573@intacc.uucp>
Date: 13 Jul 89 02:29:41 GMT
Article-I.D.: intacc.1989Jul13.022941.3573
Reply-To: mann@intacc.UUCP (Jeff Mann)
Organization: Inter/Access
Lines: 29

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  |