expose fdopendir in std::os::unix::fs::FileExt

[lolbinarycat]

Proposal

Problem statement

on posix systems, the correct way to handle a path as either file or directory while avoiding TOCTOU bugs is to use open(), then stat(), then either read or readir. this is not possible through the rust standard library.

Motivating examples or use cases

if this was made available, then crates could make a portable wrapper around it with a slightly less robust fallback.

Solution sketch

trait FileExt {
  fn into_dir(self) -> io::Result<ReadDir>;
}

Alternatives

add a fs::open_file_or_dir function that does all the cross platform fallback itself.

make this a method on OwnedFd instead.

impl TryFrom<OwnedFd> for ReadDir.

Complications

FileExt is not sealed for some reason.

Links and related work

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

[the8472]

Something like this will be part of the #259 implementation, though it'll be platform-dependent whether we can reuse an fd or have to attempt to reopen it due to undefined behavior in the spec:

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(), or [XSI] [Option Start] seekdir(), [Option End] the behavior is undefined.

since OwnedFd does not promise exclusive ownership of the underlying file description.