GDBM tries to detect inconsistencies in input database files as
early as possible. When an inconcistency is detected, a helpful
diagnostics is returned and the database is marked as needing
recovery. From this moment on, any GDBM function trying to access
the database will immediately return error code (instead of
eventually segfaulting as previous versions did). In order to
reconstruct the database and return it to healthy state, the
gdbm_recover function should be used.
Improved error checking
Removed gdbm-1.8.3 compatibility layer
Commands can be given to gdbmtool in the command line
The syntax is:
gdbmtool DBNAME COMMAND [ARGS...]
Multiple commands are separated by semicolon (take care to escape it),
e.g.:
gdbmtool t.db count\; avail
Fixed data conversion bugs in storing structured keys or content
New member in the gdbm_recovery structure: duplicate_keys.
Upon return from gdbm_recover, this member holds the number of keys
that has not been recovered, because the same key had already been stored
in the database. The actual number of stored keys is thus
recovered_keys - duplicate_keys.
Version 1.15 - 2018-06-15
GDBM tries to detect inconsistencies in input database files as early as possible. When an inconcistency is detected, a helpful diagnostics is returned and the database is marked as needing recovery. From this moment on, any GDBM function trying to access the database will immediately return error code (instead of eventually segfaulting as previous versions did). In order to reconstruct the database and return it to healthy state, the gdbm_recover function should be used.
The syntax is:
Multiple commands are separated by semicolon (take care to escape it), e.g.:
Upon return from gdbm_recover, this member holds the number of keys that has not been recovered, because the same key had already been stored in the database. The actual number of stored keys is thus recovered_keys - duplicate_keys.