Path: utzoo!utgpu!news-server.csri.toronto.edu!math.lsa.umich.edu!zaphod.mps.ohio-state.edu!samsung!cs.utexas.edu!fletcher
From: fletcher@cs.utexas.edu (Fletcher Mattox)
Newsgroups: news.software.b
Subject: Re: B-news locking (was Duplicate articles ...)
Message-ID: <15491@cs.utexas.edu>
Date: 6 Dec 90 00:50:28 GMT
References: <113417@uunet.UU.NET> <1088@ai.cs.utexas.edu> <660393258.3719@proa.sv.dg.com>
Organization: Dept of Computer Sciences, UTexas, Austin
Lines: 32

In article <660393258.3719@proa.sv.dg.com> gary@proa.sv.dg.com (Gary Bridgewater) writes:
>In article <1088@ai.cs.utexas.edu> fletcher@cs.utexas.edu (Fletcher Mattox) writes:
>>Speaking of B news locking, what prevents concurrent instances
>>of rnews from writing simultaneously to the history file?  A quick 
>>look at the code suggests savehist() could be doing this.  
>
>It happens via lock() and unlock() in ifuncs.c.  This locks - using whatever
>mechanism you have - /usr/lib/news/sys.
>It's called, generally, by localize() as the article is going to be posted.

I don't think so.  lock() and unlock() are used in three places:

  1. to protect the active file in localize(), as you note.
  2. to protect the active file in c_newgroup(), when newgroups are created.
  3. to protect the sequence file in getident(), to create unique message id.

I'm concerned about the call to savehist() from insert().
lock() doesn't protect this, as best I can tell.

I think B news history files are routinely getting corrupted,
but the damage is minimal because the file is opened for append
and probably only the last entry is getting munged.  And most
folks just don't notice.  

If true, then the dbm files are subject to the same problem.
Like UUNET, I've recently converted to dbz.  I'm wondering if
dbz's hashing scheme might be more sensitive to this kind of
corruption than dbm's was.  I.e. could an ill-timed store()
screw the entire data base?

Unless someone can show me where concurrent writes to the
history file are prevented, I'll add the code to do that.