From owner-freebsd-bugs Sat Dec 12 18:11:28 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id SAA27446 for freebsd-bugs-outgoing; Sat, 12 Dec 1998 18:11:28 -0800 (PST) (envelope-from owner-freebsd-bugs@FreeBSD.ORG) Received: from freefall.freebsd.org (freefall.FreeBSD.ORG [204.216.27.21]) by hub.freebsd.org (8.8.8/8.8.8) with ESMTP id SAA27426; Sat, 12 Dec 1998 18:11:17 -0800 (PST) (envelope-from dillon@FreeBSD.org) From: Matt Dillon Received: (from dillon@localhost) by freefall.freebsd.org (8.8.8/8.8.5) id SAA03924; Sat, 12 Dec 1998 18:11:17 -0800 (PST) Date: Sat, 12 Dec 1998 18:11:17 -0800 (PST) Message-Id: <199812130211.SAA03924@freefall.freebsd.org> To: poon@samart.co.th, dillon@FreeBSD.ORG, freebsd-bugs@FreeBSD.ORG Subject: Re: bin/3478 Sender: owner-freebsd-bugs@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org Synopsis: pwd_mkdb and passwd State-Changed-From-To: open-closed State-Changed-By: dillon State-Changed-When: Sat Dec 12 18:08:10 PST 1998 State-Changed-Why: I've committed changes to freebsd-current to have pwd_mkdb lock the specified source file while rebuilding the database. I have also fixed a small race condition in vipw/pwd_mkdb/chpass/passwd. Note, however, that no changes have been commited to the old 2.x.x-stable release as the final release (2.2.8) has been made in that branch. You can work around the problem for your particular application by writing a simple wrapper to hold a lock on master.passwd whlie you are rebuilding the db's, but if you do do that remember that if/when you ever upgrade to 3.x.x, the locking will become inherent to pwd_mkdb. -Matt To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-bugs" in the body of the message