`File::metadata()?.len()` returns 0

[bugadani]

I'm not sure where I should report issues that are either libc or std, so I hope this is either the right place or someone knows.

I'm trying to read the size of an open file. I have two options to do this:

• fs::File::metadata()
• a custom C implementation

The C impl looks like this:

size_t file_size_fd(int file) {
    struct stat st;

    if (fstat(file, &st) == 0) {
        return st.st_size;
    } else {
        return 0u;
    }
}

I have the following snippet:

    let size = unsafe { file_size_fd(f.as_raw_fd()) };
    let size2 = f.metadata().unwrap().len();

The C implementation returns the correct size (for example, 868 bytes), but the rust call gives me 0.

I'm using a fresh enough installation of esp-idf 4.3.1 and rust 1.56.0.1 [sic].

[MabezDev]

So it seems the underlying metadata() call invokes this portion of code: https://github.com/rust-lang/rust/blob/c9c4b5d7276297679387189d96a952f2b760e7ad/library/std/src/sys/unix/fs.rs#L772-L789. The libc call it makes is fstat64, however a grep of the newlib component in esp-idf shows no results, but it has got fstat implemented at least.

I think this needs to be implemented in esp-idf, or maybe we need to patch the std library to use fstat for the espidf targets.

[bugadani]

I am slightly confused by the heap of cfg macros, but isn't fstat imported as fstat64 in https://github.com/rust-lang/rust/blob/c9c4b5d7276297679387189d96a952f2b760e7ad/library/std/src/sys/unix/fs.rs#L59 for espidf targets as well?

[MabezDev]

Finally tracked this one down, it seems the definition for stat on the C/Rust border.

• size of libc::newlib::stat (Rust side), 80 bytes
• size of stat on C side: 60 bytes

Now to figure out which side is wrong, and what fields need to change.

[MabezDev]

This has now been fixed in the esp-rs/rust 1.59.0.0.1 branch, upstream PR is pending.

Compiler builds are being worked on but you are welcome to build the compiler yourself if you want to test this out!

Thanks for your patience :)

[bugadani]

Thanks a lot, I'll give it a try as soon as I can :)
Edit: actually, it looks like I've undeveloped the code that used this... Well, thanks anyway for the fix!