For the OS/2 EMX port, I build the dbm module with gdbm
v1.7.3.

At least with the OS/2 version of the gdbm v1.7.3 port,
dbm databases consist only of the .pag file - there is
no .dir file.

In this case, the .pag file has the gdbm magic number.

Currently whichdb fails to identify such dbm DBs on
this platform because of the expectation that there be
a .dir file as well as the .pag file.

I'm not in any position to confirm whether the dbm
module built with gdbm behaves the same way on other
systems -information gratefully received on this topic.

On the assumption that other platforms also have this
behaviour, the attached patch attempts to detect
whether a dbm DB has a gdbm signature just by checking
the magic number of the .pag file.

The patch involves a refactoring of the magic number
code, which may be deemed inappropriate.

It may be more expedient to just special case theEMX
port in the dbm detection (by skipping looking for the
.dir file on this platform).

Logged In: YES 
user_id=21627

The dbm module greatly varies in behaviour across platforms,
depending on what underlying library is linked. On my Linux
installation, the resulting files are identified as

/tmp/u.dir: GNU dbm 1.x or ndbm database, little endian
/tmp/u.pag: GNU dbm 1.x or ndbm database, little endian

I recommend that you adjust your patch to take dbm.library
into account, and go looking for gdbm magic only if you find
that dbm is linked with gdbm.

Logged In: YES 
user_id=250749

I've added a revised patch that attempts to address Martin's
points.

I've also added a patch that applies a workaround solely for
the only platform (OS/2 EMX) known to me to have this issue,
rather than trying to be fancy and all-encompassing.

I incline to the view that the platform specific workaround
would be safer for 2.3, with the more sophisticated approach
added after  the 2.3 release if appropriate.

Logged In: YES 
user_id=21627

I agree that the more conservative patch is better at this
point; please apply it. The regroup the patch for 2.4 and
leave it open (perhaps at a lower priority also).

Logged In: YES 
user_id=250749

OS/2 EMX specific workaround applied to whichdb.py as v1.17.

Re-grouped to 2.4; lowered to priority 3.

I'll prepare a version of the revised "complete" patch to
take into account application of the EMX workaround after
2.3 is out the door.

Logged In: YES 
user_id=250749

I can't confirm this for sure, not having gdbm installed on
my FreeBSD box, but I think that gdbm actually has only one
DB file, but creates a hard link to show both filenames.

Because EMX doesn't support link(), the hard link can't be
created, and so the gdbm just creates one of the 2 expected
files.

At this point I don't think this is worth pursuing any
further, as the EMX specific workaround meets the
requirement, and no other platforms appear to be having
problems.

Therefore I am closing this patch as not requiring any
further action.