|Anonymous | Login||2023-12-07 10:13 UTC|
|Main | My View | View Issues | Change Log | Docs|
|Viewing Issue Simple Details|
|ID||Category||Severity||Type||Date Submitted||Last Update|
|0001057||[1003.1(2004)/Issue 6] System Interfaces||Objection||Clarification Requested||2016-06-08 15:51||2019-10-23 14:25|
|Organization||The Open Group|
|Final Accepted Text||Make the changes proposed in the Desired Action.|
|Summary||0001057: Unclear how O_TRUNC and O_EXCL apply to dbm_open()|
The dbm_open() description refers to open() for the meanings of the flags in
the open_flags argument. In the case of the O_TRUNC flag it is not clear
how the description of O_TRUNC for open() applies to dbm_open(). It says:
If the file exists and is a regular file, and the file is
successfully opened O_RDWR or O_WRONLY, its length shall be
truncated to 0, and the mode and owner shall be unchanged. It
shall have no effect on FIFO special files or terminal device
files. Its effect on other file types is implementation-defined.
The result of using O_TRUNC with O_RDONLY is undefined.
Since the name passed to dbm_open() is not used to create a file with
that pathname, it is not clear whether the "length truncated to 0"
requirement is intended to apply, literally, to the underlying files
(with added .dir and .pag suffixes) or in some less literal way.
If the literal interpretation is intended, there is a problem in that
the standard does not require the underlying .dir and .pag files to be
regular files. Probably the intention is that the result of O_TRUNC
should be that the database is empty, rather than any specific effect
on the underlying files.
Additionally, it is questionable how/whether some of the other flags should
apply to dbm_open() such as O_NONBLOCK (also O_SEARCH and O_EXEC for Issue 7),
and how the existence check for O_EXCL applies to two underlying files.
It would be better if the dbm_open() page described the applicable flags
itself rather than referring to open().
Regarding O_EXCL, the suggested changes make it unspecified which of
the .pag and .dir files is opened first. This means there is a very small
risk that two concurrent attempts to create a database will both fail, but
for that to happen there would need to be two different implementations on
one system, or for the database to be on a network file system which is
accessed from systems with different implementations. Either way, this
creation failure is a small problem compared to the problems that would
likely occur if both implementations successfully open the same database.
Another aspect of O_EXCL on two-file implementations is what happens if
the first file is created and then the second file is found to exist.
A good quality implementation should remove the first file, thus leaving
the files in the same state as they were on entry to the function, but
the original BSD code did not do this and so the proposed changes have it
as a recommendation (by the use of "should") rather than a requirement.
Note that this bug has been submitted against Issue 6 as it affects
UNIX 03 certification, but the suggested changes take into account
changes already made to dbm_open() and open() in Issue 7.
On page 251 line 8245 section dbm_clearerr(), change:
The open_flags argument has the same meaning as the flags argument of open() except that a database opened for write-only access opens the files for read and write access and the behavior of the O_APPEND flag is unspecified. The file_mode argument has the same meaning as the third argument of open().to:
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_RDONLYAny combination of the following can be used:Open the database, and the underlying file(s) used to store the database, for reading only.O_RDWROpen the database, and the underlying file(s) used to store the database, for reading and writing.O_WRONLYOpen the database for writing only. The underlying file(s) used to store the database shall be opened for reading and writing.O_CLOEXECThe behaviour of other flags described for the flags argument of open() is unspecified.If set, the FD_CLOEXEC flag for the new file descriptor(s) used to open the underlying file(s) shall be set.O_CREATIf 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] Write I/O operations on the file(s) used to store the database shall complete as defined by synchronized I/O data integrity completion. [/SIO]O_EXCLIf 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.O_RSYNC
On page 253 line 8341 section dbm_clearerr(), change FUTURE DIRECTIONS from:
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.
|On Solaris, both files (.pag and .dir) are derived from the name argument and the modes from dbm_open() are forwarded unchanged to open(). Is there another implementation that requires to change the standard?|
|There are no changes needed relating to the filenames or their modes (except a minor clarification to explicitly state what was only implied before). The purpose of the proposed changes is to clarify requirements related to the O_* flags.|
|2016-06-08 15:51||geoffclare||New Issue|
|2016-06-08 15:51||geoffclare||Status||New => Under Review|
|2016-06-08 15:51||geoffclare||Assigned To||=> ajosey|
|2016-06-08 15:51||geoffclare||Name||=> Geoff Clare|
|2016-06-08 15:51||geoffclare||Organization||=> The Open Group|
|2016-06-08 15:51||geoffclare||Section||=> dbm_clearerr()|
|2016-06-08 15:51||geoffclare||Page Number||=> 251|
|2016-06-08 15:51||geoffclare||Line Number||=> 8245|
|2016-06-08 15:51||geoffclare||Interp Status||=> ---|
|2016-06-08 15:54||geoffclare||Desired Action Updated|
|2016-06-08 16:08||joerg||Note Added: 0003253|
|2016-06-09 08:15||geoffclare||Note Added: 0003255|
|2017-08-10 15:28||Don Cragun||Final Accepted Text||=> Make the changes proposed in the Desired Action.|
|2017-08-10 15:28||Don Cragun||Status||Under Review => Resolved|
|2017-08-10 15:28||Don Cragun||Resolution||Open => Accepted|
|2017-08-10 15:34||Don Cragun||Tag Attached: tc3-2008|
|2019-10-23 14:25||geoffclare||Status||Resolved => Applied|
|Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group|