From owner-freebsd-current  Sat Feb 24 23:46:51 1996
Return-Path: owner-current
Received: (from root@localhost)
          by freefall.freebsd.org (8.7.3/8.7.3) id XAA18224
          for current-outgoing; Sat, 24 Feb 1996 23:46:51 -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 XAA18218
          for <freebsd-current@FreeBSD.org>; Sat, 24 Feb 1996 23:46:42 -0800 (PST)
Received: (from bde@localhost) by godzilla.zeta.org.au (8.6.12/8.6.9) id SAA08500; Sun, 25 Feb 1996 18:45:50 +1100
Date: Sun, 25 Feb 1996 18:45:50 +1100
From: Bruce Evans <bde@zeta.org.au>
Message-Id: <199602250745.SAA08500@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

>Well, I haven't seen it happen here yet, perhaps it only breaks if the water 
>in your drain goes the wrong way?  Actually, the only reason I could imagine 
>this
>occuring is if the stat failed because you didn't have permission to access 
>the file, but then you DID have write permission to mess the file up.  Bizzare.

It seems to be a bugfeature in the getcap(3) library and/or in cap_mkdb.

"Cgetent will first look for files ending in .db (see cap_mkdb(1)) before
accessing the ASCII file."

termcap.db is built by `cap_mkdb termcap'.  cap_mkdb calls dbopen() first.
This creates an empty termcap.db (the same as before).  Then cap_mkdb
calls cgetnext().  It isn't clear why the empty termcap.db didn't get
used before.  Now it apparently gets used.

Bruce