- Various Berkeley DB methods take a mode argument, which is intended
to specify the underlying file permissions for created files. Berkeley DB
currently ignores this argument on Windows systems.
It would be possible to construct a set of security attributes to pass to
CreateFile that accurately represents the mode. In the worst
case, this would involve looking up user and all group names, and creating
an entry for each. Alternatively, we could call the _chmod
(partial emulation) function after file creation, although this leaves us
with an obvious race.
Practically speaking, however, these efforts would be largely meaningless
on a FAT file system, which only has a "readable" and "writable" flag,
applying to all users.
- On Windows, Berkeley DB supports internationalized filenames by treating all
directory paths and filenames passed to Berkeley DB methods as UTF-8 strings.
All paths are internally converted to wide character strings and passed
to the wide character variants of Windows system calls.
This allows applications to create and open databases with names that
cannot be represented with ASCII names while maintaining compatibility
with applications that work purely with ASCII paths.
Applications that operate on wide character strings can use the Windows
function WideCharToMultiByte with the code page CP_UTF8 to convert paths
to the form expected by Berkeley DB. Internally, Berkeley DB calls MultiByteToWideChar
on paths before calling Windows functions.
- On Windows/9X, files opened by multiple processes do not share data
correctly. For this reason, the DB_SYSTEM_MEM flag is implied
for any application that does not specify the DB_PRIVATE flag,
causing the system paging file to be used for sharing data.
- On all Windows platforms, system paging file memory is freed on last
close. For this reason, multiple processes sharing a database
environment created using the DB_SYSTEM_MEM flag must arrange
for at least one process to always have the environment open, or
alternatively that any process joining the environment be prepared to
re-create it.
If a system memory environment is closed by all processes, subsequent
attempts to open it will return an error. To successfully open a
transactional environment in this state, recovery must be run by the
next process to open the environment. For non-transactional
environments, applications must first remove the environment and then
reopen with the DB_CREATE flag.
- When using the DB_SYSTEM_MEM flag, Berkeley DB shared regions are
created without ACLs, which means that the regions are only accessible
to a single user. If wider sharing is appropriate (for example, both
user applications and Windows/NT service applications need to access
the Berkeley DB regions), the Berkeley DB code will need to be modified to create
the shared regions with the correct ACLs. Alternatively, by not
specifying the DB_SYSTEM_MEM flag, filesystem-backed regions
will be created instead, and the permissions on those files may be
directly specified through the DB_ENV->open method.
