Xref: utzoo comp.unix.wizards:16176 comp.lang.c:18724
Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!tut.cis.ohio-state.edu!cwjcc!hal!ncoast!allbery
From: allbery@ncoast.ORG (Brandon S. Allbery)
Newsgroups: comp.unix.wizards,comp.lang.c
Subject: Re: dbm/ndbm notes and some code.
Message-ID: <13650@ncoast.ORG>
Date: 17 May 89 21:05:22 GMT
References: <1889@yunexus.UUCP> <6847@cbmvax.UUCP>
Reply-To: allbery@ncoast.UUCP (Brandon S. Allbery)
Followup-To: comp.unix.wizards
Organization: Cleveland Public Access UN*X, Cleveland, Oh
Lines: 27

As quoted from <6847@cbmvax.UUCP> by grr@cbmvax.UUCP (George Robbins):
+---------------
| In article <1889@yunexus.UUCP> oz@yunexus.UUCP (Ozan Yigit) writes:
| > This is where the "database traversal" turns into a pumpkin.  Because of
| > internal caching of the key position for dbm_nextkey (dbm_keyptr ??),
| > which is appearently NOT adjusted for deletions, this traversal will never
| > display the key right after the one just deleted. Workaround is to save
| > all keys to be deleted, then perform all deletions once the sequential
| > traversal is complete.
| 
| Say what?  Where are you going to save this potentially unbounded list of
| to be deleted keys?  Surely there is a better solution???
+---------------

This is true, at least for dbm.  I discovered it when I wrote the "history
expire" program for my comp.sources.misc submission handler (now defunct,
but soon to return... I don't want to have to remember what articles already
came through so I can trash dups).  My solution was to change the delete()
to a write() to a temporary file, then rewind the temp file at the end of
the scan and call delete() on every key in it.  Ugh.

++Brandon
-- 
Brandon S. Allbery, moderator of comp.sources.misc	     allbery@ncoast.org
uunet!hal.cwru.edu!ncoast!allbery		    ncoast!allbery@hal.cwru.edu
      Send comp.sources.misc submissions to comp-sources-misc@<backbone>
NCoast Public Access UN*X - (216) 781-6201, 300/1200/2400 baud, login: makeuser