fs::read_dir() fails with error 0 on Linux if directory is on NTFS and contains file with filename > 255 bytes

[ariasuni]

1. Create a filename on an NTFS partition with a name > 255 bytes, e.g. 一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十一二三四五六七八九十.
2. Run this code with the path to the directory containing the file with the very long filename:

use std::env;
use std::fs::{self, ReadDir};

fn main() {
    test().unwrap();
}

fn test() -> std::io::Result<ReadDir> {
    let args: Vec<String> = env::args().collect();
    for result in fs::read_dir(&args[1])? {
        result.map(|entry| entry.path()).unwrap();
    }
    todo!()
}

I expected to see this happen: the code works until it panics on todo!()

Instead, this happened: thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Os { code: 0, kind: Other, message: "Success" }', test.rs:11:42. Note that in exa, it fails with Bad address (os error 14).

Meta

rustc --version --verbose:

rustc 1.53.0 (53cb7b09b 2021-06-17)
binary: rustc
commit-hash: 53cb7b09b00cbea8754ffb78e7e3cb521cb8af4b
commit-date: 2021-06-17
host: x86_64-unknown-linux-gnu
release: 1.53.0
LLVM version: 12.0.1

[ChrisDenton]

So NTFS has a limit of 255 UTF-16 code units. However, something here is interpreting that as being a UTF-8 byte limit of 255.

I think this error originates outside of Rust? If libc::opendir is returning a null pointer then I'm not sure what Rust can do?

[ghost]

I think this error originates outside of Rust? If libc::opendir is returning a null pointer then I'm not sure what Rust can do?

Note that the screenshots in ogham/exa#893 (comment) shows that ls works, and I don't think opendir failed because the line that panicked (line 11) is result.map(|entry| entry.path()).unwrap();. I think it was readdir_r.

I guess it reported strange errors because this is not correct:

rust/library/std/src/sys/unix/fs.rs

Line 501 in 543ab99

return Some(Err(Error::last_os_error()));

According to https://manpages.debian.org/unstable/manpages-dev/readdir_r.3.en.html#RETURN_VALUE, readdir_r "returns a positive error number" on error. It does not mention that it'll set errno, so I think Error::last_os_error() might not return the correct error.

However, the code does check the return value != 0, so I think readdir_r indeed failed. I'm not sure why, but https://manpages.debian.org/unstable/manpages-dev/readdir_r.3.en.html#DESCRIPTION and #34668 list some limitations related to long directory entry names.

[RalfJung]

It does not mention that it'll set errno, so I think Error::last_os_error() might not return the correct error code.

Ah, I was already wondering why the error message says Success. 😂

[tavianator]

So this should no longer say "success". It should say something like "file name too long" instead now. A complete fix is just replacing readdir_r() with readdir() on LInux, which I'll do unless someone beats me to it. See #40021 for some historical details.