Anonymous | Login | 2025-01-22 17:53 UTC |
Main | My View | View Issues | Change Log | Docs |
Viewing Issue Simple Details [ Jump to Notes ] | [ Issue History ] [ Print ] | ||||||
ID | Category | Severity | Type | Date Submitted | Last Update | ||
0001057 | [1003.1(2004)/Issue 6] System Interfaces | Objection | Clarification Requested | 2016-06-08 15:51 | 2024-06-10 15:47 | ||
Reporter | geoffclare | View Status | public | ||||
Assigned To | ajosey | ||||||
Priority | normal | Resolution | Accepted | ||||
Status | Closed | ||||||
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_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: 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. |
||||||
Tags | tc3-2008 | ||||||
Attached Files | |||||||
|
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |