`Directory::open` fails consistently where `std::fs::` succeeds

[mccolljr]

System Information:

Library: glommio = "0.8.0" (also reproduces with tip via glommio = { git = "https://github.com/DataDog/glommio.git" })

OS: Linux a57b2fb7965f 6.5.11-linuxkit #1 SMP PREEMPT Wed Dec 6 17:08:31 UTC 2023 aarch64 GNU/Linux

This is a Debian container (debian:stable-slim) running on Docker for Mac. The mac has an M2 Pro (so, apple silicon).

The code:

#[test]
fn test_glommio_create_dir() {
    let le = glommio::LocalExecutor::default();
    le.run(async {
        glommio::io::Directory::create("somedir") // calls `open` to get return result
            .await
            .expect("failed to create directory");
    });
}

and

#[test]
fn test_glommio_open_dir() {
    let le = glommio::LocalExecutor::default();
    le.run(async {
        glommio::io::Directory::open("target") // the cargo target directory - definitely exists
            .await
            .expect("failed to open directory");
    });
}

The result:

The first & second test panic with:

failed to (create/open) directory: EnhancedIoError { source: Os { code: 9, kind: Uncategorized, message: "Bad file descriptor" }, op: "Opening directory", path: Some("somedir"), fd: None }

In the first test, the directory is definitely created and appears on disk. In the second test, I confirmed beforehand that the directory definitely exists.

Trying to open the directory with the standard library (using the same flags as glommio) succeeds:

#[test]
fn test_glommio_open_dir_std() {
    use std::os::unix::fs::OpenOptionsExt;

    let d = std::fs::OpenOptions::new()
        .read(true)
        .custom_flags(libc::O_DIRECTORY | libc::O_CLOEXEC)
        .open("target")
        .expect("failed to open directory");

    println!("is a directory: {}", d.metadata().unwrap().is_dir())
}