Anonymous | Login | 2024-10-14 23:34 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 | ||
0000391 | [1003.1(2008)/Issue 7] System Interfaces | Editorial | Error | 2011-03-12 08:00 | 2024-06-11 08:53 | ||
Reporter | Don Cragun | View Status | public | ||||
Assigned To | ajosey | ||||||
Priority | normal | Resolution | Accepted | ||||
Status | Closed | ||||||
Name | Don Cragun | ||||||
Organization | Self | ||||||
User Reference | dirfd() ENOTSUP | ||||||
Section | dirfd() | ||||||
Page Number | 723 | ||||||
Line Number | 24338-24339 | ||||||
Interp Status | --- | ||||||
Final Accepted Text | See desired action. | ||||||
Summary | 0000391: ENOTSUP should not be a valid error for dirfd() | ||||||
Description |
The dirfd() ERRORS section includes the following description for an ENOTSUP may fail error: "The implementation does not support the association of a file descriptor with a directory." But, open() and openat() don't have an ENOTSUP error, and openat() cannot be used as described in the rest of the standard if a system doesn't support associating a file descriptor with a directory. So, implementations have to support associating a file descriptor with a directory. I believe that the dirfd() ENOTSUP error should have been removed from the standard when openat() was added. |
||||||
Desired Action |
Change the DESCRIPTION of dirfd() from: The dirfd() function shall return a file descriptor referring to the same directory as the dirp argument. This file descriptor shall be closed by a call to closedir(). If any attempt is made to close the file descriptor, or to modify the state of the associated description, other than by means of closedir(), readdir(), readdir_r(), or rewinddir(), the behavior is undefined. on P723, L24327-24330 to: If the directory stream referenced by dirp has an associated file descriptor, dirfd() shall return that file descriptor. Otherwise, dirfd() shall open a new file description referring to the directory associated with the directory stream as if by calling: open(DirectoryName, O_RDONLY | O_DIRECTORY | O_CLOEXEC); except that no pathname for use as DirectoryName need exist or be accessible. It shall then associate the new file descriptor with the directory stream, and return that file descriptor. Upon successful return from dirfd(), the file descriptor is under the control of the system, and if any attempt is made to close the file descriptor, or to modify the state of the associated description other than by means of closedir(), readdir(), readdir_r(), rewinddir(), <XSI shaded>or seekdir()</XSI shaded>, the behavior is undefined. Upon calling closedir() the file descriptor shall be closed. Editor's note: The above change includes the change to L24330 specified by the resolution of bug #422. In the RETURN VALUE section, change: and may set errno on P723, L24333 to: and shall set errno In the ERRORS section, add the following after P723, L24335: The dirfd() function shall fail if: [EMFILE] A new file descriptor is required and all file descriptors available to the process are currently open. [ENFILE] A new file desciptor is required and the maximum allowable number of files is currently open in the system. In the ERRORS section, delete the ENOTSUP may fail error on P723, L24343-24344. |
||||||
Tags | issue8 | ||||||
Attached Files | |||||||
|
Relationships | |||||||||||||||||||
|
Notes | |
(0000696) drepper (reporter) 2011-03-14 01:48 |
There is a big difference between open/openat opening a directory and opendir doing the same. The former define no I/O operation whatsoever on the file descriptor thus created. All those descriptors are good for is calling stat etc and nowadays to use as a first argument to the *at functions. There is no reason that opendir is implemented this way. There might be a much better implementation which doesn't involve file descriptors. This is why ENOTSUP was added and I think it should stay. It would be a true limitation on possible implementations to do away with it. |
(0000697) Don Cragun (manager) 2011-03-14 02:28 |
While it is true that opendir() need not use a file descriptor, fdopendir() is required to associate a file descriptor with a directory stream. Therefore, the system must support a link between a directory stream and an underlying directory's file descriptor in some circumstances (and the file descriptor is required to remain attached to the directory stream until closedir() is called; the process exits; or one of the exec family of functions, posix_spawn(), or posix_spawnp() closes the file descriptor while overlaying the current process with a new process image). I see no reason why a process shouldn't be able to use dirfd() to get a file descriptor associated with a directory stream so it can manipulate any file descriptor flags it wants to use on the underlying directory. Note that this does not preclude an implementation from using a means other than a file descriptor to access the underlying directory when opendir() is used unless dirfd() is called; it only requires that a file descriptor be associated with a directory stream if dirfd() is used on the directory stream or if fdopendir() is used to create the directory stream. |
(0000698) geoffclare (manager) 2011-03-14 09:46 |
Note that the description of opendir() on the fdopendir() page says: If the type DIR is implemented using a file descriptor, applications shall only be able to open up to a total of {OPEN_MAX} files and directories. Thus the standard allows opendir() to open a stream that does not have a fd associated with it. The question is what should dirfd() do when passed such a stream. There are two possibilities: 1. Return an error. 2. Open a file descriptor and associate it with the stream. The standard currently only seems to acknowledge the existence of the first choice (by listing ENOTSUP). For it to deal properly with the second choice there would need to be several additions: * EMFILE and ENFILE errors * A statement that the lowest available file descriptor is used * A statement about the FD_CLOEXEC flag for the opened file descriptor * Statements similar to these on the fdopendir() page: Upon successful return from fdopendir(), the file descriptor is under the control of the system, and if any attempt is made to close the file descriptor, or to modify the state of the associated description, other than by means of closedir(), readdir(), readdir_r(), or rewinddir(), the behavior is undefined. Upon calling closedir() the file descriptor shall be closed. I believe these additions ought to be made regardless of whether we decide to remove the ENOTSUP error. |
(0000780) Don Cragun (manager) 2011-05-06 05:12 |
The original Desired Action section of this bug has been replaced with text that makes the changes suggested in Note: 0000698. |
(0000781) drepper (reporter) 2011-05-06 10:40 |
Sorry for being late on this: > While it is true that opendir() need not use a file descriptor, fdopendir() is > required to associate a file descriptor with a directory stream. That's not really true. All fdopendir() is required to do is to identify the directory and the position in the directory from the file descriptor. This is a one-way mapping and there is no requirement that the file descriptor is actually used during the subsequent readdir() call. There is also no requirement that you can represent an arbitrary directory/position tuple using a file descriptor and therefore dirfd() need not work in all situations. seekdir()/telldir() work differently for a reason, they require the directory to be identified using the DIR structure. |
(0000782) eblake (manager) 2011-05-06 14:15 |
fdopendir() is required to associate a file descriptor with a stream in the sense that the application is no longer allowed to call close(fd) on that file descriptor. And coding wise, it is much easier to use openat() and friends if you can guarantee that dirfd(fdopendir(fd))==fd. It is worth making this additional requirement on implementations, even if the implementation does not otherwise use the file descriptor while implementing readdir(). Therefore, it is easier to require that the implementation keep fd open until the corresponding closedir(), rather than closing the file descriptor immediately and reopening a fresh file descriptor (likely with a different value) at a later dirfd() call. Besides, since an application is not permitted to call close(dirfd()), it makes sense that dirfd() must be required to return the same fd every time. This proposal is not changing things to require an fd be opened on opendir(), so much as to require that once an fd is associated with a directory stream (either via fdopendir or dirfd), then that same fd remains associated with the stream until closedir. The implementation need not otherwise use the associated fd from within the directory stream functions. |
(0000802) msbrown (manager) 2011-06-09 15:12 |
Targeting for the next revision. |
(0000832) Don Cragun (manager) 2011-06-14 17:39 |
The Desired Action has been updated based on comments received on the e-mail reflector. (ENOENT error removed; note that DirectoryName need not exist in the file hierarchy when dirfd() is called.) |
Mantis 1.1.6[^] Copyright © 2000 - 2008 Mantis Group |