0001057: Unclear how O_TRUNC and O_EXCL apply to dbm_open()

Austin Group Defect Tracker

Aardvark Mark IV

Viewing Issue Simple Details [ Jump to Notes ]

[ Issue History ] [ Print ]

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

Reporter

geoffclare

View Status

public

Assigned To

ajosey

Priority

normal

Resolution

Accepted

Status

Applied

Name

Geoff Clare

Organization

The Open Group

User Reference

Section

dbm_clearerr()

Page Number

251

Line Number

8245

Interp Status

---

Final Accepted Text

Make the changes proposed in the Desired Action.

Summary

0001057: Unclear how O_TRUNC and O_EXCL apply to dbm_open()

Description

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.

Desired Action

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_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] 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_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] Read I/O operations on the file(s) used to store the database shall complete at the same level of integrity as specified by the O_DSYNC and O_SYNC flags. If both O_DSYNC and O_RSYNC are set in oflag, all I/O operations on the file(s) shall complete as defined by synchronized I/O data integrity completion. If both O_SYNC and O_RSYNC are set in flags, all I/O operations on the file(s) shall complete as defined by synchronized I/O file integrity completion. [/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.

On page 253 line 8341 section dbm_clearerr(), change FUTURE DIRECTIONS from:

None.

to:

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.

Notes
(0003253) joerg (reporter) 2016-06-08 16:08	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?

(0003255) geoffclare (manager) 2016-06-09 08:15	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.

Issue History
Date Modified	Username	Field	Change
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

Relationships