From owner-freebsd-current Sun Jan 10 12:43:56 1999 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id MAA11137 for freebsd-current-outgoing; Sun, 10 Jan 1999 12:43:56 -0800 (PST) (envelope-from owner-freebsd-current@FreeBSD.ORG) Received: from gw-nl3.philips.com (gw-nl3.philips.com [192.68.44.35]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id MAA11132 for ; Sun, 10 Jan 1999 12:43:53 -0800 (PST) (envelope-from Jos.Backus@nl.origin-it.com) Received: from smtprelay-nl1.philips.com (localhost.philips.com [127.0.0.1]) by gw-nl3.philips.com with ESMTP id VAA23231 for ; Sun, 10 Jan 1999 21:43:19 +0100 (MET) (envelope-from Jos.Backus@nl.origin-it.com) Received: from smtprelay-eur1.philips.com(130.139.36.3) by gw-nl3.philips.com via mwrap (4.0a) id xma023229; Sun, 10 Jan 99 21:43:19 +0100 Received: from dibbs1.eur.cis.philips.com (dibbs1.eur.cis.philips.com [130.139.33.66]) by smtprelay-nl1.philips.com (8.8.5/8.6.10-1.2.2m-970826) with ESMTP id VAA07146 for ; Sun, 10 Jan 1999 21:43:19 +0100 (MET) Received: from hal.mpn.cp.philips.com (hal.mpn.cp.philips.com [130.139.64.195]) by dibbs1.eur.cis.philips.com (8.8.8/8.8.8) with SMTP id VAA15688 for ; Sun, 10 Jan 1999 21:43:18 +0100 (MET) Received: (qmail 13603 invoked by uid 666); 10 Jan 1999 20:43:51 -0000 Date: Sun, 10 Jan 1999 21:43:51 +0100 From: Jos Backus To: freebsd-current@FreeBSD.ORG Subject: Re: Two seem-to-be bugs with 3.0-SNAP Message-ID: <19990110214351.A13555@hal.mpn.cp.philips.com> Reply-To: Jos Backus References: <199901101747.JAA86041@apollo.backplane.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 0.95.1i In-Reply-To: <199901101747.JAA86041@apollo.backplane.com>; from Matthew Dillon on Sun, Jan 10, 1999 at 09:47:27AM -0800 Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Sun, Jan 10, 1999 at 09:47:27AM -0800, Matthew Dillon wrote: > Ah, I missed that one. pwd_mkdb was earlier modified to do locking > (which it didn't do before). So now that it does, programs that > use it shoulds either use pwd_mkdb's -N option so they can hold their > own lock all the way through, or not hold a lock. I guess pw shouldn't lock /etc/master.passwd in this case (davidn removed it), because I recall changing the call inside pw to pwd_mkdb, adding the -N flag, but that wouldn't work either because the pwdb call in pwupd.c(pw_update) would return with an error in that case (because of the LOCK_EX failing). But my memory is starting to get hazy on the subject. Cheers, -- Jos Backus _/ _/_/_/ "Reliability means never _/ _/ _/ having to say you're sorry." _/ _/_/_/ -- D. J. Bernstein _/ _/ _/ _/ Jos.Backus@nl.origin-it.com _/_/ _/_/_/ use Std::Disclaimer; To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message