Skip to content

feature request: allow safely composing dir::Dir::openat and fcntl::readlinkat with dir::OwningIter #2669

Description

@opsound

Use-case:

  • I am iterating over the contents of a directory
  • During the iteration, I want to take advantage of functions like openat and readlinkat, which act relative to a dirfd, so that I can avoid path construction, and reduce the amount of work spent in the kernel traversing path arguments.

e.g. something along the lines of

use std::ffi::OsStr;

use nix::dir::Dir;
use nix::fcntl::OFlag;
use nix::fcntl::readlinkat;
use nix::sys::stat::Mode;

let dir_iter = Dir::open("/path/to/some/dir", OFlag::O_RDONLY, Mode::empty())?.into_iter();

while let Some(dentry) = dir_iter.next() {
  let dentry = dentry?;
  let _ = readlinkat(dir_iter.as_fd(), dentry.file_name())?;
}

Currently, you can extract the raw dirfd using OwningIter::as_raw_fd, but have to be careful to not violate the contracts of dirfd(3) with respect to the owning DIR stream.

This file descriptor is the one used internally by the directory stream. As a result, it is useful only for func‐
tions which do not depend on or alter the file position, such as fstat(2) and fchdir(2). It will be automatically
closed when closedir(3) is called.

It would be nice if there was a safe way to compose Dir with other functions acting relative to a dirfd.

Activity

  1. changed the title [-]feature request: allow safely composing nix::dir::Dir::openat and nix::fcntl::readlinkat with nix::dir::OwningIter[/-] [+]feature request: allow safely composing `dir::Dir::openat` and `fcntl::readlinkat` with `dir::OwningIter`[/+] on Aug 31, 2025
  2. StripedMonkey commented on Apr 15, 2026

    @StripedMonkey

    I'm working on a program that's doing a lot of parallel file walking/iteration and am trying to minimize the amount of path traversal going on for very large trees.

    Implementing a OwningIterator::as_fd(&self) seems fairly straightforward here and is the only piece of the puzzle necessary for a safe interface. Is there any obvious blockers to simply adding it? I'd like to add it if there aren't any problems.

    Another feature that would make the interface easier for me would be to extract the Dir from the iterator after we're done with it, i.e so it can be stashed. Right now this is still possible by stashing the OwningIter but I would prefer to not have the ability to accidentally have a half-iterated directory. Rewinding (if necessary) and returning the Dir with a OwningIter::into_dir(Self) would be helpful.

  3. added 4 commits that reference this issue on Aug 1, 2026
    5f037dd
    3b42136
    5b6d759
    900f35c
  4. added a commit that references this issue on Sep 30, 2026
    05c98b4
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions