FDOPENDIR(3P)

💖 FDOPENDIR(3P) — the POSIX Programmer's Manual, but make it a group chat 💖

okay bestie, so this is fdopendir and opendir from the POSIX Programmer's Manual. quick heads up before we dive in:

⚠️ This manual page is part of the POSIX Programmer's Manual. The Linux implementation of this interface may differ (consult the corresponding Linux manual page for details of Linux behavior), or the interface may not be implemented on Linux. 💀

---

✨ NAME ✨

fdopendir, opendir — open directory associated with file descriptor 🎀

---

🦋 SYNOPSIS 🦋

#include <dirent.h>

DIR *fdopendir(int fd);
DIR *opendir(const char *dirname);

---

🌸 DESCRIPTION 🌸

so fdopendir() is literally the same vibe as opendir(), except the directory is specified by a file descriptor instead of by a name. the file offset associated with the file descriptor at the time of the call determines which entries are returned. periodt. 💅

once fdopendir() returns successfully, that file descriptor is under the control of the system. and if you try to close() the file descriptor, or modify the state of the associated description, by any means other than closedir(), readdir(), readdir_r(), rewinddir(), or seekdir() — the behavior is undefined. 🙈 not a vibe. and when you call closedir(), the file descriptor shall be closed.

also, it is unspecified whether the FD_CLOEXEC flag will be set on the file descriptor by a successful call to fdopendir().

now, opendir() opens a directory stream corresponding to the directory named by the dirname argument. the directory stream is positioned at the first entry. and heads up: 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. 👑

also if the type DIR is implemented using a file descriptor, the descriptor shall be obtained as if the O_DIRECTORY flag was passed to open().

---

💜 RETURN VALUE 💜

upon successful completion, these functions shall return a pointer to an object of type DIR. ✨ otherwise, these functions shall return a null pointer and set errno to indicate the error. 😭

---

🔥 ERRORS 🔥

fdopendir() shall fail if:

• EBADF — the fd argument is not a valid file descriptor open for reading.
• ENOTDIR — the descriptor fd is not associated with a directory.

opendir() shall fail if:

• EACCES — search permission is denied for the component of the path prefix of dirname, or read permission is denied for dirname.
• ELOOP — a loop exists in symbolic links encountered during resolution of the dirname argument.
• ENAMETOOLONG — the length of a component of a pathname is longer than {NAME_MAX}.
• ENOENT — a component of dirname does not name an existing directory, or dirname is an empty string.
• ENOTDIR — a component of dirname names an existing file that is neither a directory nor a symbolic link to a directory.

opendir() may fail if:

• ELOOP — more than {SYMLOOP_MAX} symbolic links were encountered during resolution of the dirname argument.
• EMFILE — all file descriptors available to the process are currently open.
• ENAMETOOLONG — the length of a pathname exceeds {PATH_MAX}, or pathname resolution of a symbolic link produced an intermediate result with a length that exceeds {PATH_MAX}.
• ENFILE — too many files are currently open in the system.

The following sections are informative. (iykyk 🫶)

---

🎀 EXAMPLES 🎀

Open a Directory Stream

this little program fragment shows how the opendir() function is used. so cute, so classic. 🌈

#include <dirent.h>
...
    DIR *dir;
    struct dirent *dp;
...
    if ((dir = opendir (".")) == NULL) {
        perror ("Cannot open .");
        exit (1);
    }

    while ((dp = readdir (dir)) != NULL) {
...

Find And Open a File

okay this one is the main character: it searches through a given directory looking for files whose name does not begin with a dot and whose size is larger than 1 MiB. 🔥

#include <stdio.h>
#include <dirent.h>
#include <fcntl.h>
#include <sys/stat.h>
#include <stdint.h>
#include <stdlib.h>
#include <unistd.h>

int
main(int argc, char *argv[])
{
    struct stat statbuf;
    DIR *d;
    struct dirent *dp;
    int dfd, ffd;

    if ((d = fdopendir((dfd = open("./tmp", O_RDONLY)))) == NULL) {
        fprintf(stderr, "Cannot open ./tmp directory\n");
        exit(1);
    }
    while ((dp = readdir(d)) != NULL) {
        if (dp->d_name[0] == '.')
            continue;
        /* there is a possible race condition here as the file
         * could be renamed between the readdir and the open */
        if ((ffd = openat(dfd, dp->d_name, O_RDONLY)) == -1) {
            perror(dp->d_name);
            continue;
        }
        if (fstat(ffd, &statbuf) == 0 && statbuf.st_size > (1024*1024)) {
            /* found it ... */
            printf("%s: %jdK\n", dp->d_name,
                (intmax_t)(statbuf.st_size / 1024));
        }
        close(ffd);
    }
    closedir(d); // note this implicitly closes dfd
    return 0;
}

---

🧚 APPLICATION USAGE 🧚

ngl, you should use opendir() together with readdir(), closedir(), and rewinddir() to examine the contents of the directory (see the EXAMPLES section in readdir()). this method is recommended for portability. slay responsibly. 💖

---

👑 RATIONALE 👑

the whole point of fdopendir() is to enable opening files in directories other than the current working directory without exposure to race conditions. because any part of the path of a file could be changed in parallel to a call to opendir(), resulting in unspecified behavior. 😭 scary fr fr.

based on historical implementations, the rules about file descriptors apply to directory streams as well. however, this volume of POSIX.1‐2017 does not mandate that the directory stream be implemented using file descriptors. the description of closedir() clarifies that if a file descriptor is used for the directory stream, it is mandatory that closedir() deallocate the file descriptor. and when a file descriptor is used to implement the directory stream, it behaves as if the FD_CLOEXEC had been set for the file descriptor.

the directory entries for dot and dot-dot are optional. this volume of POSIX.1‐2017 does not provide a way to test a priori for their existence, because an application that is portable must be written to look for (and usually ignore) those entries. writing code that presumes they're the first two entries does not always work, since many implementations permit them to be other than the first two entries, with a ``normal'' entry preceding them. there is negligible value in providing a way to determine what the implementation does, because the code to deal with dot and dot-dot must be written in any case, and because such a flag would add to the list of those flags (which has proven in itself to be objectionable) and might be abused. 💀

since the structure and buffer allocation, if any, for directory operations are defined by the implementation, this volume of POSIX.1‐2017 imposes no portability requirements for erroneous program constructs, erroneous data, or the use of unspecified values such as the use or referencing of a dirp value or a dirent structure value after a directory stream has been closed or after a fork() or one of the exec function calls. 🙈

---

⭐ FUTURE DIRECTIONS ⭐

None. (nothing to see here bestie, it's giving calm 🌸)

---

💫 SEE ALSO 💫

closedir(), dirfd(), fstatat(), open(), readdir(), rewinddir(), symlink()

the Base Definitions volume of POSIX.1‐2017, <dirent.h>, <sys_types.h>

---

📜 COPYRIGHT 📜

Portions of this text are reprinted and reproduced in electronic form from IEEE Std 1003.1-2017, Standard for Information Technology -- Portable Operating System Interface (POSIX), The Open Group Base Specifications Issue 7, 2018 Edition, Copyright (C) 2018 by the Institute of Electrical and Electronics Engineers, Inc and The Open Group. In the event of any discrepancy between this version and the original IEEE and The Open Group Standard, the original IEEE and The Open Group Standard is the referee document. The original Standard can be obtained online at http://www.opengroup.org/unix/online.html .

Any typographical or formatting errors that appear in this page are most likely to have been introduced during the conversion of the source files to man page format. To report such errors, see https://www.kernel.org/doc/man-pages/reporting_bugs.html .

---

and that's the whole page bestie!! 🫶 it went out under IEEE/The Open Group, dated 2017, and yes, the manual page itself is literally titled FDOPENDIR(3P). go read a directory or something, ily, bye 💅✨🎀