find_mountpoint

文档在此：这里.

这个库最初是一个简单的 crate，用于简化获取从 macOS 的 statfs(2) 返回的一个字段的操作。它处理所有不安全的东西，并且反映了我作为 Rust 新手的最佳理解，即如何高效地处理 libc 内存管理。它现在已经增长了一些，并且应该可以在 Rust 支持的所有平台上工作。

它的错误处理相当保守。它不使用 .unwrap()，因此除非你未能处理自己的代码中的 Result，否则它永远不会崩溃。我创建了一个新的 find_mountpoint::Error，它是对我调用的错误类型进行求和的类型，这在 Rust 书中被认为是惯用的。

尽管 macOS 版本进行了不安全调用，但我尽量将其全部放在一个关键部分中，以最大限度地减少可能发生的问题。由于我的目标之一是最大限度地减少内存开销，我考虑使用静态变量来处理传递给 statfs(2) 的缓冲区，但后来意识到这将使其在多线程代码或与 Tokio 一起使用时不安全，因此每个调用都会为 statfs 结构分配新的内存。

自从开发 macOS 版本以来，我还编写了一个（较慢的）版本，该版本不依赖于 libc，并且应该可以在所有其他 UNIX 变体上运行。还有一个更简单的 Windows 版本，它在 AppVeyor 上通过了测试，所以也许它也会对友好的 Windows 开发者有用。我使用的 Windows API 的示例代码在 GitHub 上比较少：这里.

话虽如此，我在AppVeyor上完成项目并使测试通过只花了不到半小时的时间，这要归功于这个配置和rustup。一切迅速集成的速度相当令人印象深刻。谢谢，Rust！太棒了！

这是我发布的第一个Rust crate，因此我确信即使是这段简短的代码也存在我愿意帮助修复的问题。目前关于libc::statfs的使用示例并不多，几乎每个人都做了一些我做的变体，但是欢迎提出问题和Pull Request。

理由

处理libc调用相当麻烦（&str → Path → OsStr → CStr然后再回来，仅仅为了字符串！）。nix在其Statfs结构中未公开我想要的字段。我找到的任何文件系统crate都没有公开这个函数。如果有人想将其整合到他们的库中，或者与我合作将此函数合并到他们的crate中（包括nix），那将是极好的！