root/handle: readdir wrappers?

[cyphar]

Rust's stdlib doesn't provide a way for users to construct a ReadDir iterator (nor DirEntry) so if someone wants to implement an iterator over subtrees using libpathrs they would need to manually use rustix and adopt the logic we have for iteration in src/utils/dir.rs.

I suspect these would be Rust-only helpers since exporting them to C would be quite ugly.

[warpfork]

Just dropping a quick +1 here: I'd really like to be able to do this!

The API of this library overall is What I Want in a big way -- opening a root and resolving a series of paths relative to it is both logically and safety/stability-wise exactly what I'm looking for in almost all the code I ever write regarding the filesystem. (So, thanks to everyone who built and contributes to this!)

So I'm super enthusiastic to pretty much ditch as much std::fs usage in Rust as I can, and move fully over to this API as consistently and completely as possible in my projects. For both the safety gains and for code quality.

The escape valves around Handle and getting either a raw fd or using .reopen(...) to convert over to std::fs::File in Rust are great. However, they're a little clunky (and in the case of std::fs::File in Rust, don't accomplish everything: one can't get to an readdir APIs when starting from that position in the standard library!). The more that can be done without leaving libpathrs, the happier I would be.

I haven't tried to use rustix yet and it sounds promising. But I'd likely be in favor of seeing some more ready-made integration there (even if it becomes somewhat rust specific). Or at least some docs and examples showing how it can be done would be great, because I bet I'm not going to be the last person to want this :)

[cyphar]

The slightly ugly thing is that without non-'static GATs you can't get a nice iterator interface that doesn't require making a copy of the underlying file descriptor (at least, that's the limitation that rustix::fs::Dir and rustix::fs::RawDir have).

I wonder whether it makes sense for us to export a half-baked interface for this, or if we should wait for it to be possible to write a nice interface? Maybe we should have some docs explaining how to do this though...