Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site burl.UUCP
Path: utzoo!watmath!clyde!burl!rcj
From: rcj@burl.UUCP (Curtis Jackson)
Newsgroups: net.news.adm
Subject: zero-length article bug found in inews.c et. al.
Message-ID: <830@burl.UUCP>
Date: Mon, 26-Aug-85 14:43:32 EDT
Article-I.D.: burl.830
Posted: Mon Aug 26 14:43:32 1985
Date-Received: Wed, 28-Aug-85 01:55:34 EDT
Reply-To: rcj@burl.UUCP (Curtis Jackson)
Organization: AT&T Technologies, Burlington NC
Lines: 56
Keywords: BUG

If you are running 2.10.2 news you may have this bug; I'm not sure.
If you are running 2.10.2 news with the DOXREFS stuff in inews.c for rn,
you DO have this bug (or I missed the fix):

When inews is installing a new article in the spool directory, the DOXREFS
version creates a temp file, links the temp file to the correct article
number in the proper subdirectory under /usr/spool/news, writes the temp
file (and the real file by default), then removes the temp file.

There is a comment on line 629 of my inews.c source just prior to the
write that says:

	/* (We ought to detect no room at this point and clean up.) */

Yes, we ought to, but we don't.
lhwrite() is called, which calls ihwrite(), which writes out the
article header using printf() without checking the return value.  Upon
return to inews from lhwrite(), the inews.c code then writes the
article itself using putc() and fputs() without checking return value.

This means that if your filesystem runs out of data blocks instead of
inodes, that the link will succeed; creating a zero-length article file.
But the writes into that file will silently fail, and the zero-length
file remains as a "valid" article.

My fix would be:

a) Have lhwrite()/ihwrite() check each printf() return value and return a
non-zero value to the calling function on the first printf() failure.

b) Have the article-body-writing code in inews.c use fputc() instead of
putc() so a return value can be checked.

c) Have the article-body-writing code in inews.c check the return value of
fputs().

As for what cleanup should be done upon write error, I have no idea;
perhaps one of the inews gurus could enlighten?

An aside question:  I run Sys V r2, and in the manuals under putc(3S)
DIAGNOSTICS it says that fputc() will return the constant EOF if the stream
given has not been opened for writing "or if the output file cannot be grown."
The DIAGNOSTICS for fputs() under puts(3S), on the other hand, say only
that EOF will be returned if the file has not been opened for writing.
I assume (dangerous, I know) that fputs() returns EOF for no room like fputc()
does?

Aside question #2:  Will these zero-length articles be removed by expire
at some time in the future?

Answer to #2 especially appreciated,
-- 

The MAD Programmer -- 919-228-3313 (Cornet 291)
alias: Curtis Jackson	...![ ihnp4 ulysses cbosgd mgnetp ]!burl!rcj
			...![ ihnp4 cbosgd akgua masscomp ]!clyde!rcj