rcj@burl.UUCP (Curtis Jackson) (08/26/85)
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
dunlap@stride1.UUCP (D. Christopher Dunlap) (08/29/85)
In article <830@burl.UUCP> rcj@burl.UUCP (Curtis Jackson) writes: > >Aside question #2: Will these zero-length articles be removed by expire >at some time in the future? > >The MAD Programmer -- 919-228-3313 (Cornet 291) >alias: Curtis Jackson ...![ ihnp4 ulysses cbosgd mgnetp ]!burl!rcj > ...![ ihnp4 cbosgd akgua masscomp ]!clyde!rcj I have been getting a lot of "garbled articles" in junk, I think the mail I'm getting about them comes from expire. When I go to the junk directory, all the articles are of zero length. Could this be related? -- D. Christopher Dunlap Stride Micro, Reno, NV UUCP: cbosgd!utah-cs!utah-gr!stride!dunlap Phone: (702) 322-6868 TWX: 910-395-6073
wls@astrovax.UUCP (William L. Sebok) (09/06/85)
In article <830@burl.UUCP> rcj@burl.UUCP (Curtis Jackson) writes: >Aside question #2: Will these zero-length articles be removed by expire >at some time in the future? No they won't be removed, not even by expire -r. Every so often I have to go through and remove them by hand. -- Bill Sebok Princeton University, Astrophysics {allegra,akgua,cbosgd,decvax,ihnp4,noao,philabs,princeton,vax135}!astrovax!wls
lmcl@ukc.UUCP (L.M.McLoughlin) (09/12/85)
Expire on a pdp11 is a highly untrustworthy program. I advise a weekly (or
more often if space is tight) "find /usr/spool/news -type f -a -mtime +DAYS
-a -exec rm -f {} \;" where DAYS is one more than your expire time (the
extra day is a margin of error).
I started this when I discovered about a meg of old news files that expire was
ignoring.
Of course if anyone out there has actually managed to fix it I'd be most
grateful for a copy.