1. 25
  1.  

  2. 7

    This sounds like a great improvement. When I profiled my little web server algernon, os.Stat was one of the slowest functions.

    I wonder when and why in the history of UNIX it was decided to bundle so much information about files into one system call, and if having separate system calls per type of file information returned by stat would give better performance.

    1. 7

      I wonder when and why in the history of UNIX it was decided to bundle so much information about files into one system call, and if having separate system calls per type of file information returned by stat would give better performance.

      I assume this is because all the metadata that stat() returns (inode, mode, UID, GID, size) is stored in a single block; I bet that in traditional UNIX systems this was just the stat_t struct written to disk and reading just the UID wasn’t (and probably still isn’t) really all that faster than just reading everything. I assume that modern filesystems kept this, while also adding their own metadata extensions.

    2. 2

      The new design seems similar to Rust’s with fs::read_dir and fs::DirEntry. Notably DirEntry::metadata is free on Windows, but uses something like stat on Unix. DirEntry::file_type is free on all common platforms.

      1. 1

        Interesting! Python’s scandir / DirEntry and Rust’s read_dir / DirEntry are indeed quite similar. I wonder if this Rust API was modeled somewhat after the Python one. I found an RFC that mentions read_dir and DirEntry, but it doesn’t give many details or link to discussion, so I’m not sure.