text: #include <db.h>
  int memp_fopen(DB_ENV *env, char *file, u_int32_t flags, int mode, size_t pagesize, DB_MPOOL_FINFO *finfop, DB_MPOOLFILE **mpf);
  The memp_fopen function opens a file in the pool specified by the DB_ENV env, copying the DB_MPOOLFILE pointer representing it into the memory location to which mpf refers.
  The file argument is the name of the file to be opened. If file is NULL, a private temporary file is created that cannot be shared with any other process (although it may be shared with other threads).
  The flags and mode arguments specify how files will be opened and/or created if they do not already exist.
  The flags value must be set to 0 or by bitwise inclusively OR'ing together one or more of the following values:
  On UNIX systems or in IEEE/ANSI Std 1003.1 (POSIX) environments, all files created by function memp_fopen are created with mode mode (as described in chmod(2)) and modified by the process' umask value at the time of creation (see umask(2)). If mode is 0, function memp_fopen will use a default mode of readable and writable by both owner and group. On Windows systems, the mode argument is ignored. The group ownership of created files is based on the system and directory defaults, and is not further specified by Berkeley DB.
  The pagesize argument is the size, in bytes, of the unit of transfer between the application and the pool, although it is not necessarily the unit of transfer between the pool and the source file.
  Files opened in the pool may be further configured based on the finfop argument to memp_fopen (which is a pointer to a structure of type DB_MPOOL_FINFO). No references to the finfop structure are maintained by Berkeley DB, so it may be discarded when the memp_fopen function returns. In order to ensure compatibility with future releases of Berkeley DB, all fields of the DB_MPOOL_FINFO structure that are not explicitly set should be initialized to 0 before the first time the structure is used. Do this by declaring the structure external or static, or by calling memset(3).
  The fields of the DB_MPOOL_FINFO structure used by memp_fopen are described as follows. If finfop is NULL or any of its fields are set to their default value, defaults appropriate for the system are used.
  The mpool functions must be able to uniquely identify files in order that multiple processes wanting to share a file will correctly identify it in the pool.
  On most UNIX/POSIX systems, the fileid field will not need to be set, and the mpool functions will simply use the file's device and inode numbers for this purpose. On Windows systems, the mpool memory buffer pool between processes or across system reboots, in which the pool contains pages from files stored on such filesystems, must specify a unique file identifier to the memp_fopen call, and each process opening or registering the file must provide the same unique identifier.
  This should not be necessary for most applications. Specifically, it is not necessary if the memory pool is not shared between processes and is reinstantiated after each system reboot, if the application is using the Berkeley DB access methods instead of calling the pool functions explicitly, or if the files in the memory pool are stored on filesystems in which the default values as described previously are invariant between process and across system reboots.
  The memp_fopen function returns a non-zero error value on failure and 0 on success.
  The memp_fopen function may fail and return a non-zero error for the following conditions:
  The file has already been entered into the pool, and the pagesize value is not the same as when the file was entered into the pool, or the length of the file is not zero or a multiple of the pagesize.
  The DB_RDONLY flag was specified for an in-memory pool.
  The memp_fopen function may fail and return a non-zero error for errors specified for other Berkeley DB and C library or system functions. If a catastrophic error has occurred, the memp_fopen function may fail and return DB_RUNRECOVERY, in which case all subsequent Berkeley DB calls will fail in the same way.