(Contributed by Oleg Broytmann.)

(From SF patch #810751)

At this point, the problem appears particular to the OS/2 EMX port of
gdbm (which is at v1.7.3) - this combination produces a .pag file but
no .dir file.

A more sophisticated patch which checks magic numbers when dbm.library
indicates that dbm is linked to gdbm, and there is no .dir file, is
still attached to the above patch entry for reconsideration after 2.3
is released.

This checkin applies a workaround specific to the known failure case.

module to load them

functions.  In this case, calling dbm.open("foo", "c") actually creates a
file named "foo.db".

This closes bug 200 on Jitterbug.

I guess in 1.5.2 a new module, whichdb, was added that attempts to
divine the nature of a database file.  This module doesn't know anything
about Berkeley DB v2 files.  In v2, Sleepycat added a 12-byte null pad
in front of the old magic numbers (at least for hash and btree files).
I've been using v2 for awhile and upgrading to 1.5.2 broke all my
anydbm.open calls. I believe the following patch corrects the problem.