Path: utzoo!utstat!helios.physics.utoronto.ca!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cheops.cis.ohio-state.edu!karl
From: karl@cheops.cis.ohio-state.edu (Karl Kleinpaste)
Newsgroups: news.software.b
Subject: Re: rn and NFS; large search strings and mangled .newsrc's
Message-ID: <KARL.89Dec2162508@cheops.cis.ohio-state.edu>
Date: 2 Dec 89 21:25:08 GMT
References: <41292@srcsip.UUCP>
Sender: news@tut.cis.ohio-state.edu
Organization: OSU
Lines: 26
In-reply-to: jkimball@SRC.Honeywell.COM's message of 1 Dec 89 21:50:31 GMT

jkimball@SRC.Honeywell.COM writes:
   (Maybe a news.software.readers would make sense -- where *should* you post
   something about newsreader software?)

I'd say, Right where you did.

   2) Possibly related:  occasionally 'rn' suddenly believes that your .newsrc
      doesn't exist, and so it merrily creates you a new one (blowing away the
      one which did exist.)  Often it is the 'news biff' invocation of "rn -c"
      which does this.  I tracked down where the message ("running newsetup")
      is coming from, in rcstuff.c -- a .newsrc is built when fopen(rcname,"r")
      returns "Nullfp".  Why would it return Nullfp when the file exists?

NFS timeouts on soft-mounted filesystems.  We have the same problem,
and it's quite irritating.  Personally, I'd rather stay with
hard-mounted filesystems, because our fileserver reliability is quite
high, but local policy is for soft mounts.  Ohwell.

I suggest that you insert a check around the fopen(), to see if a
"long time" passed between the time that the fopen was attempted and
when it came back.  If it failed and the amount of time is "long"
(fuzzy - define in your own best terms), have rn try it again.  Give
it a max retry of, say, 5 - that will allow a reasonable amount of
time for your fileserver to catch up with rn.

--karl