From: bobl@bobsbox.rent.com (Bob Lindabury - SysAdmin)
Newsgroups: alt.sys.amiga.uucp
Subject: Re: Cnews questions
Date: 11 Dec 92 03:38:27 GMT
Organization: Raven Enterprises -- Piscataway, NJ USA
X-NewsSoftware: GRn 1.16f (10.17.92) by Mike Schwartz & Michael B. Smith

In article <091292d0514@hamburg.uucp> wusel@hactar.hanse.de (Kai 'wusel' Siering) writes:
> In article <1992Dec8.031915.1784@ckctpa.UUCP>, crash@ckctpa.UUCP (Frank "Crash" Edwards) writes:
> % hugh@kink.PhaedraV.On.Ca (Hugh D. Gamble) writes:
> % >I tracked it down, but never fixed it because it was going to be a
> % >pain, and I wasn't batching enough news for the added cost of using
> % >"F" to amount to much, and because there are so many other things I'd
> % >like to fix in that port that I'm planning to do a clean port from
> % >scratch one of these days.
> % >
> % >The problem is that relaynews calculates the article length before the
> % >xref line gets added. This means that any locally posted articles that
> % >are crossposted will have the wrong length and get thrown out by
> % >upstream sites.
> %
> % Hmmm.  Are you saying that when the article gets batched, the "#!
> % rnews" header is incorrect?  That would be strange 'cuz it's the
> % batcher's job to put the right byte count on the article, and it
>
>      Not exactly; with `..:f:' you tell relaynews to add the size of the
> article -- if a batcher depends on this (possibly incorrect) value ...
>
> % shouldn't be affected by relaynews at all (it just reads the filenames
> % out of the togo file and creates a batchfile to xmit).
>
> True for `F', false for `f'.

I imagine we are talking about the :f: bug in relaynews using the sys
file.  I found that out after I changed it from :F: to :f: only to find
that every site I was feeding news to had "out of sync tossing news"
errors.  I had only changed the f variable so I knew what it was almost
immediately.

Has anyone fixed this?

Also, I'm probably being a dweeb here but my unbatch script seems to
want to do a complete processing of the entire Newsarts:in.coming
directory instead of on a file by file basis...meaning it will first
acomp every .z file, then it will unbatch every file in the directory
and then it will delete all the files.  Of course this amounts to TONS
of wasted space when processing news.  Say I get 20 megs of compressed
news in one pass..the files all get copied to newsarts:in.coming by
rnews and then later processed by unbatch.  This can result in around
25-30 megs of uncompressed batched news which then has to be unbatched
taking up an additional 30-40 megs making a single groups of 20
compressed and batched news files requiring a whopping total of 60 megs
of HD space just to process.

Does anyone have the script line that will tell unbatch to acomp,
unbatch and then delete each file one at a time instead of the current
list LFORMAT >filename method?  It would save me untold grief.

Thanks.

--
 Bob Lindabury

InterNet: bobl@bobsbox.rent.com                | Raven Enterprises
    UUCP: ...rutgers!bobsbox!bobl              | 25 Raven Avenue
  BitNet: bobl%bobsbox.rent.com@pucc           | Piscataway, NJ 08854
  Home #: +1 908/560-7353                      | +1 908/271-8878