Skip to content

Consider adding a Dir::into_fd() method #1455

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
linkmauve opened this issue Apr 30, 2025 · 1 comment
Open

Consider adding a Dir::into_fd() method #1455

linkmauve opened this issue Apr 30, 2025 · 1 comment

Comments

@linkmauve
Copy link

linkmauve commented Apr 30, 2025

Currently, once an OwnedFd has been passed to rustix::fs::Dir, there is no way to reuse it.

My usecase is to call rustix::fs::openat() and rustix::fs::statat() on it after I’m done with the iteration (or even during, I don’t think there is any issue with that since getdents64(2) is stateless).

My current solution is to call rustix::io::dup() on the fd before creating the Dir, but that shouldn’t be needed and wastes one fd. Another solution would be to rustix::fs::open() it again once the iteration is done, but that’s wasteful too.

rustix::fs::Dir::read_from has the same issue, it implements dup(2) manually by calling fcntl(4, F_GETFL) then openat(4, ".", …) with 4 being the fd being passed to it.

And since getdents64(2) is stateless, I believe there is no unsoundness issue with e.g. multiple rustix::fs::Dir being created around the same fd.

@sunfishcode
Copy link
Member

The tricky thing here is that rustix is aiming to have the same API across both the libc and linux-raw backends, and in the libc backend, it uses opendir/readdir/closedir. libc doesn't have a way to free a DIR object without closing the fd.

One option might be to have the libc backend implement into_fd by calling dup before calling closedir, however I'm not sure if it's too awkward if into_fd() has to be fallible.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants