Date: Mon, 26 Feb 1996 06:54:00 +1100 From: Bruce Evans <bde@zeta.org.au> To: bde@zeta.org.au, pst@shockwave.com Cc: freebsd-current@freebsd.org, jhay@mikom.csir.co.za Subject: Re: Bug in libc/db/hash/hash.c??? Message-ID: <199602251954.GAA32445@godzilla.zeta.org.au>
next in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199602251954.GAA32445>