GDBM(3) | GDBM User Reference | GDBM(3) |
GDBM - The GNU database manager. Includes dbm and ndbm compatibility.
#include <gdbm.h> extern gdbm_error gdbm_errno;
extern char *gdbm_version;
extern int gdbm_version[3];
GDBM_FILE gdbm_open (const char *name, int block_size, int flags, int mode, void (*fatal_func)(const char *));
int gdbm_close (GDBM_FILE dbf);
int gdbm_store (GDBM_FILE dbf, datum key, datum content, int flag);
datum gdbm_fetch (GDBM_FILE dbf, datum key);
int gdbm_delete (GDBM_FILE dbf, datum key);
datum gdbm_firstkey (GDBM_FILE dbf);
datum gdbm_nextkey (GDBM_FILE dbf, datum key);
int gdbm_recover (GDBM_FILE dbf, gdbm_recovery *rcvr, intflags);
int gdbm_reorganize (GDBM_FILE dbf);
int gdbm_sync (GDBM_FILE dbf);
int gdbm_exists (GDBM_FILE dbf, datum key);
const char *gdbm_strerror (gdbm_error errno);
int gdbm_setopt (GDBM_FILE dbf, int option, int value, int size);
int gdbm_fdesc (GDBM_FILE dbf);
int gdbm_count (GDBM_FILE dbf, gdbm_count_t *pcount);
int gdbm_bucket_count (GDBM_FILE dbf, size_t *pcount);
int gdbm_avail_verify (GDBM_FILE dbf);
int gdbm_failure_atomic (GDBM_FILE dbf, const
char *even, const char *odd);
int gdbm_latest_snapshot (const char *even, const char
*odd, const char **result);
This manpage is a short description of the GDBM library. For a detailed discussion, including examples and usage recommendations, refer to the GDBM Manual available in Texinfo format. To access it, run:
info gdbm
The documentation is also available online at
https://www.gnu.org/software/gdbm/manual
Should any discrepancies occur between this manpage and the GDBM Manual, the later shall be considered the authoritative source.
GNU dbm is a library of routines that manages data files that contain key/data pairs. The access provided is that of storing, retrieval, and deletion by key and a non-sorted traversal of all keys. A process is allowed to use multiple data files at the same time.
A process that opens a gdbm file is designated as a "reader" or a "writer". Only one writer may open a gdbm file and many readers may open the file. Readers and writers can not open the gdbm file at the same time. The procedure for opening a gdbm file is:
GDBM_FILE gdbm_open (const char *name, int block_size, int flags, int mode, void (*fatal_func)(const char *));
Name is the name of the file (the complete name, gdbm does not append any characters to this name).
Block_size is the size of a single transfer from disk to memory. If the value is less than 512, the file system block size is used instead. The size is adjusted so that the block can hold exact number of directory entries, so that the effective block size can be slightly greater than requested. This adjustment is disabled if the GDBM_BSEXACT flag is used.
The flags parameter is a bitmask, composed of the access mode and one or more modifier flags. The access mode bit designates the process as a reader or writer and must be one of the following:
Additional flags (modifiers) can be combined with these values by bitwise OR. Not all of them are meaningful with all access modes.
Flags that are valid for any value of access mode are:
Finally, never use GDBM_PREREAD when opening a database for updates, especially for inserts: this will degrade performance.
This flag has no effect if GDBM_NOMMAP is given, or if the operating system does not support prefault reading. It is known to work on Linux and FreeBSD kernels.
The following additional flags are valid when the database is opened for writing (GDBM_WRITER, GDBM_WRCREAT, or GDBM_NEWDB):
NOTE: this option entails severe performance degradation and does not necessarily ensure that the resulting database state is consistent, therefore we discourage its use. For a discussion of how to ensure database consistency with minimal performance overhead, see CRASH TOLERANCE below.
The following flags can be used together with GDBM_NEWDB. They also take effect when used with GDBM_WRCREAT, if the requested database file doesn't exist:
Without this flag, gdbm_open will silently adjust the block_size to a usable value, as described above.
Mode is the file mode (see chmod(2) and open(2)). It is used if the file is created.
Fatal_func is a function to be called when gdbm if it encounters a fatal error. This parameter is deprecated and must always be NULL.
The return value is the pointer needed by all other routines to access that gdbm file. If the return is the NULL pointer, gdbm_open was not successful. In this case, the reason of the failure can be found in the gdbm_errno variable. If the following call returns true (non-zero value):
gdbm_check_syserr(gdbm_open)
the system errno variable must be examined in order to obtain more detail about the failure.
GDBM_FILE gdbm_fd_open (int FD, const char *name, int block_size, int flags, int mode, void (*fatal_func)(const char *));
This is an alternative entry point to gdbm_open. FD is a valid file descriptor obtained as a result of a call to open(2) or creat(2). The function opens (or creates) a DBM database this descriptor refers to. The descriptor is not dup'ed, and will be closed when the returned GDBM_FILE is closed. Use dup (2) if that is not desirable.
In case of error, the function behaves like gdbm_open and does not close FD. This can be altered by the following value passed in flags:
The rest of arguments are the same as for gdbm_open.
All GDBM functions take as their first parameter the database handle (GDBM_FILE), returned from gdbm_open or gdbm_fd_open.
Any value stored in the GDBM database is described by datum, an aggregate type defined as:
typedef struct {
char *dptr;
int dsize; } datum;
The dptr field points to the actual data. Its type is char * for historical reasons. Actually it should have been typed void *. Programmers are free to store data of arbitrary complexity, both scalar and aggregate, in this field.
The dsize field contains the number of bytes stored in dptr.
The datum type is used to describe both keys and content (values) in the database. Values of this type can be passed as arguments or returned from GDBM function calls.
GDBM functions that return datum indicate failure by setting its dptr field to NULL.
Functions returning integer value, indicate success by returning 0 and failure by returning a non-zero value (the only exception to this rule is gdbm_exists, for which the return value is reversed).
If the returned value indicates failure, the gdbm_errno variable contains an integer value indicating what went wrong. A similar value is associated with the dbf handle and can be accessed using the gdbm_last_errno function. Immediately after return from a function, both values are exactly equal. Subsequent GDBM calls with another dbf as argument may alter the value of the global gdbm_errno, but the value returned by gdbm_last_errno will always indicate the most recent code of an error that occurred for that particular database. Programmers are encouraged to use such per-database error codes.
Sometimes the actual reason of the failure can be clarified by examining the system errno value. To make sure its value is meaningful for a given GDBM error code, use the gdbm_check_syserr function. The function takes error code as argument and returns 1 if the errno is meaningful for that error, or 0 if it is irrelevant.
Similarly to gdbm_errno, the latest errno value associated with a particular database can be obtained using the gdbm_last_syserr function.
The gdbm_clear_error clears the error indicator (both GDBM and system error codes) associated with a database handle.
Some critical errors leave the database in a structurally inconsistent state. If that happens, all subsequent GDBM calls accessing that database will fail with the GDBM error code of GDBM_NEED_RECOVERY (a special function gdbm_needs_recovery is also provided, which returns true if the database handle given as its argument is structurally inconsistent). To return such databases to consistent state, use the gdbm_recover function (see below).
The GDBM_NEED_RECOVERY error cannot be cleared using gdbm_clear_error.
This section describes the error handling functions outlined above.
Notice that not all gdbm_error codes have a relevant system error code. Use the following function to determine if a given code has.
The GDBM_NEED_RECOVERY error cannot be cleared.
It is important that every database file opened is also closed. This is needed to update the reader/writer count on the file. This is done by:
On error, returns 0 and sets gdbm_errno.
If the dptr element of the return value is NULL, the gdbm_errno variable should be examined. The value of GDBM_ITEM_NOT_FOUND means no data was found for that key. Other value means an error occurred.
Otherwise the return value is a pointer to the found data. The storage space for the dptr element is allocated using malloc(3). GDBM does not automatically free this data. It is the programmer's responsibility to free this storage when it is no longer needed.
The following two routines allow for iterating over all items in the database. Such iteration is not key sequential, but it is guaranteed to visit every key in the database exactly once. (The order has to do with the hash values.)
After successful return from both functions, dptr points to data allocated by malloc(3). It is the caller responsibility to free the data when no longer needed.
A typical iteration loop looks like:
datum key, nextkey, content; key = gdbm_firstkey (dbf); while (key.dptr)
{
content = gdbm_fetch (dbf, key);
/* Do something with key and/or content */
nextkey = gdbm_nextkey (dbf, key);
free (key.dptr);
key = nextkey;
}
These functions are intended to visit the database in read-only algorithms. Avoid any database modifications within the iteration loop. File visiting is based on a hash table. The gdbm_delete and, in most cases, gdbm_store, functions rearrange the hash table to make sure that any collisions in the table do not leave some item `un-findable'. Thus, a call to either of these functions changes the order in which the keys are ordered. Therefore, these functions should not be used when iterating over all the keys in the database. For example, the following loop is wrong: it is possible that some keys will not be visited or will be visited twice if it is executed:
key = gdbm_firstkey (dbf); while (key.dptr)
{
nextkey = gdbm_nextkey (dbf, key);
if (some condition)
gdbm_delete ( dbf, key );
free (key.dptr);
key = nextkey;
}
The return value is 0 if there was a successful delete or -1 on error. In the latter case, the gdbm_errno value GDBM_ITEM_NOT_FOUND indicates that the key is not present in the database. Other gdbm_errno values indicate failure.
If a function leaves the database in structurally inconsistent state, it can be recovered using the gdbm_recover function.
You can pass NULL as rcvr and 0 as flags, if no such control is needed.
By default, this function first checks the database for inconsistencies and attempts recovery only if some were found. The special flags bit GDBM_RCVR_FORCE instructs gdbm_recovery to skip this check and to perform database recovery unconditionally.
GDBM database files can be exported (dumped) to so called flat files or imported (loaded) from them. A flat file contains exactly the same data as the original database, but it cannot be used for searches or updates. Its purpose is to keep the data from the database for restoring it when the need arrives. As such, flat files are used for backup purposes, and for sending databases over the wire.
As of GDBM version 1.21, there are two flat file formats. The ASCII file format encodes all data in Base64 and stores not only key/data pairs, but also the original database file metadata, such as file name, mode and ownership. Files in this format can be sent without additional encapsulation over transmission channels that normally allow only ASCII data, such as, e.g. SMTP. Due to additional metadata they allow for restoring an exact copy of the database, including file ownership and privileges, which is especially important if the database in question contained some security-related data. This is the preferred format.
Another flat file format is the binary format. It stores only key/data pairs and does not keep information about the database file itself. It cannot be used to copy databases between different architectures. The binary format was introduced in GDBM version 1.9.1 and is retained mainly for backward compatibility.
The following functions are used to export or import GDBM database files.
int format, int open_flag, int mode) Dumps the database file dbf to the file filename in requested format. Allowed values for format are: GDBM_DUMP_FMT_ASCII, to create an ASCII dump file, and GDBM_DUMP_FMT_BINARY, to create a binary dump.The value of open_flag tells gdbm_dump what to do if filename already exists. If it is GDBM_NEWDB, the function will create a new output file, replacing it if it already exists. If its value is GDBM_WRCREAT, the file will be created if it does not exist. If it does exist, gdbm_dump will return error.
The file mode to use when creating the output file is defined by the mode parameter. Its meaning is the same as for open(2).
int flag, int meta_mask, unsigned long *errline) Loads data from the dump file filename into the database pointed to by pdbf. If pdbf is NULL, the function will try to create a new database. On success, the new GDBM_FILE object will be stored in the memory location pointed to by pdbf. If the dump file carries no information about the original database file name, the function will set gdbm_errno to GDBM_NO_DBNAME and return -1, indicating failure.Otherwise, if pdbf points to an already open GDBM_FILE, the function will load data from filename into that database.
The flag parameter controls the function behavior if a key from the dump file already exists in the database. See the gdbm_store function for its possible values.
The meta_mask parameter can be used to disable restoring certain bits of file's meta-data from the information in the input dump file. It is a binary OR of zero or more of the following:
It will not return until the disk file state is synchronized with the in-memory state of the database.
Possible values of option are:
By default, a newly open database is configured to adapt the cache size to the number of index buckets in the database file. This provides for the best performance.
Use this option if you wish to limit the memory usage at the expense of performance. If you chose to do so, please bear in mind that cache becomes effective when its size is greater then 2/3 of the number of index bucket counts in the database. The best performance results are achieved when cache size equals the number of buckets.
This option is retained for compatibility with previous versions of GDBM.
NOTE: setting this option entails severe performance degradation and does not necessarily ensure that the resulting database state is consistent, therefore we discourage its use. For a discussion of how to ensure database consistency with minimal performance overhead, see CRASH TOLERANCE below.
The GDBM_CENTFREE alias is provided for compatibility with earlier versions.
By default GNU dbm does not protect the integrity of its databases from corruption or destruction due to failures such as power outages, operating system kernel panics, or application process crashes. Such failures could damage or destroy the underlying database.
Starting with release 1.21 GNU dbm includes a mechanism that, if used correctly, enables post-crash recovery to a consistent state of the underlying database. This mechanism requires OS and filesystem support and must be requested when gdbm is compiled. The crash-tolerance mechanism is a "pure opt-in" feature, in the sense that it has no effects whatsoever except on those applications that explicitly request it. For details, see the chapter Crash Tolerance in the GDBM manual.
The version information is kept in two places. The version of the library is kept in the gdbm_version_number variable, described above. Additionally, the header file gdbm.h defines the following macros:
You can use this to compare whether your header file corresponds to the library the program is linked with.
The following function can be used to compare two version numbers:
Inspect the value of the system errno variable to get more detailed diagnostics.
Inspect the value of the system errno variable to get more detailed diagnostics.
Inspect the value of the system errno variable to get a more detailed diagnostics.
Inspect the value of the system errno variable to get a more detailed diagnostics.
The GDBM_ILLEGAL_DATA is an alias for this error code, maintained for backward compatibility.
GDBM_OPT_ILLEGAL is an alias for this error code, maintained for backward compatibility. Modern applications should not use it.
This error can be set by the following functions: gdbm_open, gdbm_reorganize.
This error can be set by any GDBM function that does I/O. Some of these functions are: gdbm_delete, gdbm_exists, gdbm_fetch, gdbm_export, gdbm_import, gdbm_reorganize, gdbm_firstkey, gdbm_nextkey, gdbm_store.
The database needs recovery.
The database needs recovery.
Database recovery is needed.
This error is set by gdbm_open and gdbm_fd_open when called with the GDBM_NEWDB flag.
GDBM includes a compatibility library libgdbm_compat, for use with programs that expect traditional UNIX dbm or ndbm interfaces, such as, e.g. Sendmail. The library is optional and thus may be absent in some binary distributions.
As the detailed discussion of the compatibility API is beyond the scope of this document, below we provide only a short reference. For details, see the GDBM Manual, chapter Compatibility with standard dbm and ndbm.
In dbm compatibility mode only one file may be opened at a time. All users are assumed to be writers. If the database file is read only, it will fail as a writer, but will be opened as a reader. All returned pointers in datum structures point to data that the compatibility library will free. They should be treated as static pointers (as standard UNIX dbm does).
The following interfaces are provided:
#include <dbm.h>
int dbminit (const char *name);
int store (datum key, datum content);
datum fetch (datum key);
int delete (datum key);
datum firstkey (void);
datum nextkey (datum key);
int dbmclose (void);
In this mode, multiple databases can be opened. Each database is identified by a handle of type DBM *. As in the original NDBM, all returned pointers in datum structures point to data that will be freed by the compatibility library. They should be treated as static pointers.
The following interfaces are provided:
#include <ndbm.h>
DBM *dbm_open (const char *name, int
flags, int mode);
void dbm_close (DBM *file);
datum dbm_fetch (DBM *file, datum key);
int dbm_store (DBM *file, datum key, datum
content, int flags);
int dbm_delete (DBM *file, datum key);
datum dbm_firstkey (DBM *file);
datum dbm_nextkey (DBM *file, datum key);
int dbm_error (DBM *file);
int dbm_clearerr (DBM *file);
int dbm_pagfno (DBM *file);
int dbm_dirfno (DBM *file);
int dbm_rdonly (DBM *file);
This library is accessed by specifying -lgdbm as the last parameter to the compile line, e.g.:
gcc -o prog prog.c -lgdbm
If you wish to use the dbm or ndbm compatibility routines, you must link in the gdbm_compat library as well. For example:
gcc -o prog proc.c -lgdbm -lgdbm_compat
Send bug reports to <bug-gdbm@gnu.org>.
by Philip A. Nelson, Jason Downs and Sergey Poznyakoff; crash tolerance by Terence Kelly.
Copyright © 1990 - 2021 Free Software Foundation, Inc.
GDBM is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 1, or (at your option) any later version.
GDBM is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with GDBM. If not, see <http://gnu.org/licenses/gpl.html>
You may contact the original author by:
e-mail: phil@cs.wwu.edu
us-mail: Philip A. Nelson
Computer Science Department
Western Washington University
Bellingham, WA 98226
You may contact the current maintainers by:
e-mail: downsj@downsj.com
and
e-mail: gray@gnu.org
For questions and feedback regarding crash tolerance, you may
contact Terence Kelly at:
e-mail: tpkelly @ { acm.org, cs.princeton.edu, eecs.umich.edu }
October 18, 2021 | GDBM |