To summarize: It is an optimization that DBM files do not shrink when keys are deleted. Shuffling the bits around on disk every time a key is deleted would be too slow. Instead, the space is reused the next time a key is inserted. Read the aforementioned thread for more details.

If you're concerned, you can simply create a new DBM. If you've got enough memory, pull the hash into memory, close the DBM, delete the files, and reopen it and re-store, like:

dbmopen %FOO, "my_db", 0666 or die;
... populate %FOO
... delete some stuff from %FOO
{
  my %TEMP = %FOO; # cache it in memory
  dbmclose %FOO;
  unlink <my_db*>; # danger, but general enough {grin}
  dbmopen %FOO, "my_db", 0666 or die;
  %FOO = %TEMP;
}
[download]

-- Randal L. Schwartz, Perl hacker

If you're concerned about disc space, though, I'm going to assume that the files are very large, ergo, unlikely to fit in memory... you'd likely want to do something like:

dbmopen %ORIG, "original", 0666 or die;
dbmopen %NOVA, "new", 0666 or die;
# -- race condition start
for my $key (keys %ORIG)
{
 $NOVA{$key} = $ORIG{$key};
}
dbmclose %ORIG;
dbmclose %NOVA;
unlink "original"
link "new", "original"
# race condition end
unlink "new";
[download]

So long as no-one else needs to get at your DBM while you're "shrinking" it, the above will work.

But keys() will still build quite a large list. You may prefer while (my($k,$v) = each %hash) instead.

japhy -- Perl and Regex Hacker

That won't work unless you know how to turn "new" into the actual list of files involved for that database. Perhaps "new.db", or even "new.dir" and "new.page".

-- Randal L. Schwartz, Perl hacker

Any reason for using dbmopen rather than tie?

Yes, abject simplicity. {grin}

-- Randal L. Schwartz, Perl hacker

I can't quote an exact answer or url to give you, but I experienced the same thing when I started using hash databaes for tasks. This is the PROPER behavior for a DBM, so if your worried about disk usage, revert back to a flat text file or get into something more robust like MySQL.

I used this technique on a low-traffic Wiki clone. A once-a-week scheduled rebuild usually shrank the DBM by 60%.