From:	AITGW::"mark%INFOCOMM.COM@VM1.NoDak.EDU"  7-AUG-1991 20:10:27.49
To:	Multiple recipients of list ANU-NEWS <ANU-NEWS@NDSUVM1>
CC:	
Subj:	Re: newsrc/diskquota

Received: by AITGW.DECnet (utk-mail11 v1.5) ; Wed, 7 Aug 91 20:08:08 EDT
Received: from vm1.NoDak.edu by aitgw.ge.com (5.61/GE Gateway 1.3)
	id AA21751; Wed, 7 Aug 91 20:05:52 -0400
Message-Id: <9108080005.AA21751@aitgw.ge.com>
Received: from NDSUVM1.BITNET by VM1.NoDak.EDU (IBM VM SMTP R1.2.1MX) with BSMTP id 5269; Wed, 07 Aug 91 19:04:22 CDT
Received: from NDSUVM1.BITNET by NDSUVM1.BITNET (Mailer R2.07) with BSMTP id
 7900; Wed, 07 Aug 91 19:04:21 CDT
Date:         Wed, 7 Aug 1991 19:40:00 GMT
Reply-To: mark%INFOCOMM.COM@VM1.NoDak.EDU
Sender: ANU-NEWS Discussion <ANU-NEWS@VM1.NoDak.EDU>
From: mark%INFOCOMM.COM@VM1.NoDak.EDU
Subject:      Re: newsrc/diskquota
To: Multiple recipients of list ANU-NEWS <ANU-NEWS@NDSUVM1>
 
In article <1991Aug7.111345.32574@kuhub.cc.ukans.edu>, sloane@kuhub.cc.ukans.edu
 (Bob Sloane) writes:
> In <9108071348.AA21227@noc1.dccs.upenn.edu>, ROSS@MSCF.MED.UPENN.EDU writes:
>>A user made a normal exit from NEWS but was low on diskquota due to extracting
>>a number of files during his news session and his newsrc file became truncated
>>...
>> Subsequent startups of NEWS resulted in access violation and memory dump.
>>
>> I suppose that news should check diskquota (could see if space is available
>> equal to or slightly larger than the previous newsrc) and if not, then
>> give the option to not update the newsrc file or to allow the user to
>> delete some files to make room for the updated newsrc file.
>
> While it would be nice if NEWS checked the quota, a more reasonable
> fix would be to check the status of the creation/writing and not
> replace the old NEWSRC file if there are any problems writing the new
> one.  If you check for "out of disk quota" should you also check for
> "disk full", "No delete permission on NEWSRC", and all of the other
> things that might go wrong?  It would end up taking significantly
> longer to exit from news in the normal case where everything goes
> correctly. Just checking the appropiate status returns would go a long
> way toward fixing this problem, and wouldn't add a lot of overhead.
> --
> USmail: Bob Sloane, University of Kansas Computer Center, Lawrence, KS, 66045
> E-mail: sloane@kuhub.cc.ukans.edu, sloane@ukanvax.bitnet, AT&T: (913)864-0444
 
I once sent in the following, quick and dirty (but effective), fix to this
problem:
 
*** newsrc.c_old
--- newsrc.c
**************
*** 443,449
 
    if (cp = strchr(n_r_c,';')) *cp = '\0';
 
!   if (!(newsrc = fopen(n_r_n,"w","mbc=40"))) {
      err_line("Cannot access NEWS register file");
      return(0);
      }
--- 443,449 -----
 
    if (cp = strchr(n_r_c,';')) *cp = '\0';
 
!   if (!(newsrc = fopen(n_r_n,"w","mbc=40","alq=120","fop=tef"))) {
      err_line("Cannot access NEWS register file");
      return(0);
      }
 
I chose this, since it seems that the VAX C runtime library can't always be
counted on to return a useful error status when a particular file operation
won't get done right.  Also, I would have been a MUCH more significant rewrite
to the whole NEWSRC.C routine write_reg_file.  I chose an allocation quantity
of 120 since my NEWSRC file is now about 73 blocks, and I wanted to give
sufficient slop so that users with lots of extra junk in their profiles and
with all sorts of scattered items having been read, end up having this
protection also.
 
--
Mark Pizzolato - INFO COMM Computer Consulting, Redwood City, Ca
PHONE:  (415)369-9366   UUCP:  decwrl!infopiz!mark or uunet!lupine!infopiz!mark
DOMAIN: mark@infocomm.com
