From owner-freebsd-current Sun Feb 25 11:56:28 1996 Return-Path: owner-current Received: (from root@localhost) by freefall.freebsd.org (8.7.3/8.7.3) id LAA15068 for current-outgoing; Sun, 25 Feb 1996 11:56:28 -0800 (PST) Received: from godzilla.zeta.org.au (godzilla.zeta.org.au [203.2.228.19]) by freefall.freebsd.org (8.7.3/8.7.3) with SMTP id LAA15056 for ; Sun, 25 Feb 1996 11:56:19 -0800 (PST) Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id GAA32445; Mon, 26 Feb 1996 06:54:00 +1100 Date: Mon, 26 Feb 1996 06:54:00 +1100 From: Bruce Evans Message-Id: <199602251954.GAA32445@godzilla.zeta.org.au> To: bde@zeta.org.au, pst@shockwave.com Subject: Re: Bug in libc/db/hash/hash.c??? Cc: freebsd-current@freebsd.org, jhay@mikom.csir.co.za Sender: owner-current@freebsd.org Precedence: bulk > I think the fix works because the O_CREAT flag is now honoured (perhaps > it should check O_TRUNC too?). I think the database was messed up when > cgetnext() opened it without (O_CREAT | O_TRUNC). >Do you mean it should require both O_CREAT and O_TRUNC or either? If either, >that case is covered earlier. I'm not certain both should be required if >the file is already 0 sized. However, I'm easy going, whichever you want >is fine by me, just as long as you clarify what you want. :-) I think backing it out was best :-). 0-length database files shouldn't exist unless another process is initializing them, and you can't fix a 0-length `cap' database file except by deleting it. >Yeah, it looks like paging to disk is rather asynchronous in nature. In my Did we break something by using mmap? >opinion, the whole damn thing should internally be protected with advisory >locks, but that completely breaks ndbm semantics where the callers expect >to have to lock the database themselves. Sigh. pwd_mkdb uses O_EXCL and a temporary database. I think that's the only way to ensure that writing the database doesn't corrupt it. Bruce