dbm_clearerr, dbm_close, dbm_delete, dbm_error, dbm_fetch, dbm_firstkey, dbm_nextkey, dbm_open, dbm_store — database functions
[XSI]#include <ndbm.h>
int dbm_clearerr(DBM *db);
void dbm_close(DBM *db);
int dbm_delete(DBM *db, datum key);
int dbm_error(DBM *db);
datum dbm_fetch(DBM *db, datum key);
datum dbm_firstkey(DBM *db);
datum dbm_nextkey(DBM *db);
DBM *dbm_open(const char *file, int open_flags, mode_t file_mode);
int dbm_store(DBM *db, datum key, datum content, int store_mode);
These functions create, access, and modify a database.
A datum consists of at least two members, dptr and dsize. The dptr member points to an object that is dsize bytes in length. Arbitrary binary data, as well as character strings, may be stored in the object pointed to by dptr.
A database shall be stored in one or two files. When one file is used, the name of the database file shall be formed by appending the suffix .db to the file argument given to dbm_open(). When two files are used, the names of the database files shall be formed by appending the suffixes .dir and .pag respectively to the file argument.
The dbm_open() function shall open a database. The file argument to the function is the pathname of the database. Values for the open_flags argument are constructed by a bitwise-inclusive OR of flags from the following list, defined in <fcntl.h>. Applications shall specify exactly one of the first three values (file access modes) below in the value of open_flags:
- O_RDONLY
- Open the database, and the underlying file(s) used to store the database, for reading only.
- O_RDWR
- Open the database, and the underlying file(s) used to store the database, for reading and writing.
- O_WRONLY
- Open the database for writing only. The underlying file(s) used to store the database shall be opened for reading and writing.
Any combination of the following can be used:
- O_CLOEXEC
- If set, the FD_CLOEXEC flag for the new file descriptor(s) used to open the underlying file(s) shall be set.
- O_CREAT
- If the database exists, this flag has no effect except as noted under O_EXCL below. Otherwise, the database shall be created; the user ID of the underlying file(s) shall be set to the effective user ID of the process; the group ID of the underlying file(s) shall be set to the group ID of the file's parent directory or to the effective group ID of the process. Implementations shall provide a way to initialize the group ID to the group ID of the parent directory. Implementations may, but need not, provide an implementation-defined way to initialize the group ID to the effective group ID of the calling process.
- O_DSYNC
- [SIO]
- O_EXCL
- If O_CREAT and O_EXCL are set, dbm_open() shall fail if the database exists according to the following criteria. If the database is stored in a file with a .db suffix, a check for the existence of the file and the creation of the file if it does not exist shall be performed as a single atomic operation. If the database is stored in files with .pag and .dir suffixes, this atomic existence check and creation operation shall be performed for each file, but it is unspecified which file is first. If the first file is successfully created and the second file is found to exist, the first file should be removed before dbm_open() returns.
If O_EXCL is set and O_CREAT is not set, the result is undefined.
- O_RSYNC
- [SIO]
- O_SYNC
- Write I/O operations on the file(s) used to store the database shall complete as defined by synchronized I/O file integrity completion.
- O_TRUNC
- If the database exists and is successfully opened O_RDWR or O_WRONLY, it shall be emptied, and the mode and owner of the underlying file(s) shall be unchanged. The result of using O_TRUNC without either O_RDWR or O_WRONLY is undefined.
The behaviour of other flags described for the flags argument of open() is unspecified.
The file_mode argument has the same meaning as the third argument of open() and shall apply to the underlying file(s) used to store the database.
The dbm_open() function need not accept pathnames longer than {PATH_MAX}-4 bytes (including the terminating null), or pathnames with a last component longer than {NAME_MAX}-4 bytes (excluding the terminating null).
The dbm_close() function shall close a database. The application shall ensure that argument db is a pointer to a dbm structure that has been returned from a call to dbm_open().
These database functions shall support an internal block size large enough to support key/content pairs of at least 1023 bytes.
The dbm_fetch() function shall read a record from a database. The argument db is a pointer to a database structure that has been returned from a call to dbm_open(). The argument key is a datum that has been initialized by the application to the value of the key that matches the key of the record the program is fetching.
The dbm_store() function shall write a record to a database. The argument db is a pointer to a database structure that has been returned from a call to dbm_open(). The argument key is a datum that has been initialized by the application to the value of the key that identifies (for subsequent reading, writing, or deleting) the record the application is writing. The argument content is a datum that has been initialized by the application to the value of the record the program is writing. The argument store_mode controls whether dbm_store() replaces any pre-existing record that has the same key that is specified by the key argument. The application shall set store_mode to either DBM_INSERT or DBM_REPLACE. If the database contains a record that matches the key argument and store_mode is DBM_REPLACE, the existing record shall be replaced with the new record. If the database contains a record that matches the key argument and store_mode is DBM_INSERT, the existing record shall be left unchanged and the new record ignored. If the database does not contain a record that matches the key argument and store_mode is either DBM_INSERT or DBM_REPLACE, the new record shall be inserted in the database.
If the sum of a key/content pair exceeds the internal block size, the result is unspecified. Moreover, the application shall ensure that all key/content pairs that hash together fit on a single block. The dbm_store() function shall return an error in the event that a disk block fills with inseparable data.
The dbm_delete() function shall delete a record and its key from the database. The argument db is a pointer to a database structure that has been returned from a call to dbm_open(). The argument key is a datum that has been initialized by the application to the value of the key that identifies the record the program is deleting.
The dbm_firstkey() function shall return the first key in the database. The argument db is a pointer to a database structure that has been returned from a call to dbm_open().
The dbm_nextkey() function shall return the next key in the database. The argument db is a pointer to a database structure that has been returned from a call to dbm_open(). The application shall ensure that the dbm_firstkey() function is called before calling dbm_nextkey(). Subsequent calls to dbm_nextkey() return the next key until all of the keys in the database have been returned.
The dbm_error() function shall return the error condition of the database. The argument db is a pointer to a database structure that has been returned from a call to dbm_open().
The dbm_clearerr() function shall clear the error condition of the database. The argument db is a pointer to a database structure that has been returned from a call to dbm_open().
The dptr pointers returned by these functions may point into static storage that may be changed by subsequent calls.
These functions need not be thread-safe.
The dbm_store() and dbm_delete() functions shall return 0 when they succeed and a negative value when they fail.
The dbm_store() function shall return 1 if it is called with a flags value of DBM_INSERT and the function finds an existing record with the same key.
The dbm_error() function shall return 0 if the error condition is not set and return a non-zero value if the error condition is set.
The return value of dbm_clearerr() is unspecified.
The dbm_firstkey() and dbm_nextkey() functions shall return a key datum. When the end of the database is reached, the dptr member of the key is a null pointer. If an error is detected, the dptr member of the key shall be a null pointer and the error condition of the database shall be set.
The dbm_fetch() function shall return a content datum. If no record in the database matches the key or if an error condition has been detected in the database, the dptr member of the content shall be a null pointer.
The dbm_open() function shall return a pointer to a database structure. If an error is detected during the operation, dbm_open() shall return a (DBM *)0.
No errors are defined.
None.
The following code can be used to traverse the database:
for(key = dbm_firstkey(db); key.dptr != NULL; key = dbm_nextkey(db))The dbm_* functions provided in this library should not be confused in any way with those of a general-purpose database management system. These functions do not provide for multiple search keys per entry, they do not protect against multi-user access (in other words they do not lock records or files), and they do not provide the many other useful database functions that are found in more robust database management systems. Creating and updating databases by use of these functions is relatively slow because of data copies that occur upon hash collisions. These functions are useful for applications requiring fast lookup of relatively static information that is to be indexed by a single key.
Note that a strictly conforming application is extremely limited by these functions: since there is no way to determine that the keys in use do not all hash to the same value (although that would be rare), a strictly conforming application cannot be guaranteed that it can store more than one block's worth of data in the database. As long as a key collision does not occur, additional data may be stored, but because there is no way to determine whether an error is due to a key collision or some other error condition (dbm_error() being effectively a Boolean), once an error is detected, the application is effectively limited to guessing what the error might be if it wishes to continue using these functions.
The dbm_delete() function need not physically reclaim file space, although it does make it available for reuse by the database.
After calling dbm_store() or dbm_delete() during a pass through the keys by dbm_firstkey() and dbm_nextkey(), the application should reset the database by calling dbm_firstkey() before again calling dbm_nextkey(). The contents of these files are unspecified and may not be portable.
Applications should take care that database pathname arguments specified to dbm_open() are not prefixes of unrelated files. This might be done, for example, by placing databases in a separate directory.
Since some implementations use three characters for a suffix and others use four characters for a suffix, applications should ensure that the maximum portable pathname length passed to dbm_open() is no greater than {PATH_MAX}-4 bytes, with the last component of the pathname no greater than {NAME_MAX}-4 bytes.
Previously the standard required the database to be stored in two files, one file being a directory containing a bitmap of keys and having .dir as its suffix. The second file containing all data and having .pag as its suffix. This has been changed not to specify the use of the files and to allow newer implementations of the Berkeley DB interface using a single file that have evolved while remaining compatible with the application programming interface. The standard developers considered removing the specific suffixes altogether but decided to retain them so as not to pollute the application file name space more than necessary and to allow for portable backups of the database.
A future revision of this standard may mandate the file removal that is currently recommended (by the use of "should") in the description of O_EXCL.
First released in Issue 4, Version 2.
Moved from X/OPEN UNIX extension to BASE.
Normative text previously in the APPLICATION USAGE section is moved to the DESCRIPTION.
A note indicating that these functions need not be reentrant is added to the DESCRIPTION.
The normative text is updated to avoid use of the term "must" for application requirements.
Austin Group Interpretation 1003.1-2001 #042 is applied so that the DESCRIPTION permits newer implementations of the Berkeley DB interface.
Austin Group Interpretation 1003.1-2001 #156 is applied.
Austin Group Defect 1057 is applied, clarifying how the O_ flags defined for use with open() apply to dbm_open().
![[Option End]](../images/opt-end.gif)