Austin Group Defect Tracker

Aardvark Mark IV

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 2020-02-21 16:31
Reporter Don Cragun View Status public  
Assigned To ajosey
Priority normal Resolution Accepted  
Status Applied  
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

        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,

Tags issue8
Attached Files

- Relationships
related to 0000422Closedajosey 1003.1(2008)/Issue 7 list of functions that can modify the state of a directory stream file description is incomplete 
related to 0000572Closedajosey 1003.1(2008)/Issue 7 dirfd() ENOTSUP can never happen 
related to 0001359Applied Issue 8 drafts dirfd() rationale out of date 

-  Notes
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.
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
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

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.
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.
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.
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.
msbrown (manager)
2011-06-09 15:12

Targeting for the next revision.
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.)

- Issue History
Date Modified Username Field Change
2011-03-12 08:00 Don Cragun New Issue
2011-03-12 08:00 Don Cragun Status New => Under Review
2011-03-12 08:00 Don Cragun Assigned To => ajosey
2011-03-12 08:00 Don Cragun Name => Don Cragun
2011-03-12 08:00 Don Cragun Organization => Self
2011-03-12 08:00 Don Cragun User Reference => dirfd() ENOTSUP
2011-03-12 08:00 Don Cragun Section => dirfd()
2011-03-12 08:00 Don Cragun Page Number => 723
2011-03-12 08:00 Don Cragun Line Number => 24338-24339
2011-03-12 08:00 Don Cragun Interp Status => ---
2011-03-14 01:48 drepper Note Added: 0000696
2011-03-14 02:28 Don Cragun Note Added: 0000697
2011-03-14 09:46 geoffclare Note Added: 0000698
2011-05-06 05:12 Don Cragun Note Added: 0000780
2011-05-06 05:12 Don Cragun Desired Action Updated
2011-05-06 05:14 Don Cragun Relationship added related to 0000422
2011-05-06 10:40 drepper Note Added: 0000781
2011-05-06 14:15 eblake Note Added: 0000782
2011-05-07 00:16 Don Cragun Desired Action Updated
2011-06-09 15:09 msbrown Tag Attached: issue8
2011-06-09 15:12 msbrown Note Added: 0000802
2011-06-09 15:12 msbrown Resolution Open => Future Enhancement
2011-06-14 17:39 Don Cragun Note Added: 0000832
2011-06-14 17:39 Don Cragun Desired Action Updated
2011-06-16 16:07 nick Status Under Review => Resolved
2011-06-16 16:08 nick Final Accepted Text => See desired action.
2011-06-16 16:08 nick Resolution Future Enhancement => Accepted
2012-05-30 16:22 eblake Relationship added related to 0000572
2020-02-21 16:31 geoffclare Status Resolved => Applied
2020-06-30 15:15 geoffclare Relationship added related to 0001359

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker