*_at 系统调用用于 Rust (*nix 和 Windows)

Rust 标准库尚未提供 at-style 文件系统调用作为核心功能。例如 mkdirat。这些调用对于编写无竞态条件的文件系统代码至关重要，因为否则所执行的操作的文件系统路径的状态可能会在无声中改变，导致 TOC-TOU 竞态条件。对于 Unix，这些调用在 libc crate 中可以轻松获得，但对于 Windows，则需要更多的管道。这个 crate 为这些调用提供了一个统一的 Rust-y 和安全的接口。

并非所有平台在底层系统调用上的行为都相同，这个 crate 不会抽象基本差异，但它试图为关键场景提供一致的错误。以一个具体的例子来说，在禁用 follow 的情况下，在现有链接的路径下创建目录会导致 AlreadyExists 错误。

在 Linux 上，这是通过回读请求的路径来实现的，因为原子 mkdir 尚未可用。mkdirat 被用于确保父目录是可靠的，但无法排除指向文件系统另一部分的链接的存在。

在 Windows 上，这种相同的场景将导致 fs_at 从 NtCreateFile 接收 NotADirectory 错误，或者打开成功，但使用 DeviceIoControl 执行无竞态检测链接的存在。两种情况都报告为 AlreadyExists。存在两个代码路径，因为 Windows 中的符号链接本身可以是文件或目录，内核会在链接目标和链接源上对某些操作（如创建目录或截断文件）进行类型检查。

Truncate+nofollow 也因平台而异：请参阅 OpenOptions::truncate。

MSRV 政策

只要容易，我就会保持这个编译器针对较旧的 rusts，但不会以大量代码高尔夫或旧版本依赖项中的过去 CVE 为代价。目前 MSRV 是 1.71。如果对旧版本有大量兴趣，我愿意接受补丁。

使用方法

请参阅文档。简而言之：使用fs_at::OpenOptions，类似于std::fs::OpenOptions。

与其它crate相比

openat

openat是对Unix *at功能的良好封装。它不支持Windows，并且还需要采用新的Dir结构，该结构拥有fd，这增加了与std其他部分的互操作性摩擦。

cap_std

cap_std是对许多系统交互作为能力操作的精彩重新思考。甚至比openat更进一步，它放弃了熟悉的std API，而是提供了一个自己的完整生态系统。

遗憾的是，它并没有充分利用底层操作系统的全部功能——在某些情况下（例如Windows、一些非Linux系统），它是在Rust自己的IO堆栈之上进行封装的（例如Windows、一些非Linux系统），这导致了对TOCTOU的关注。显然，随着时间的推移这是可以修复的——如果您需要一个高级API，该API将使不安全的使用变得困难，我认为cap-std是完美的。

fs_at的目标并不是重新定义我们进行IO的方式，而只是以一种直观的方式展示这些重要的调用。也许当cap_std完成时，它可以在fs_at之上进行封装。

贡献

在Github上按照常规方式提交PR。

覆盖率 - 考虑使用grcov。

export RUSTFLAGS="-Cinstrument-coverage"
export LLVM_PROFILE_FILE="fs-at-%p-%m.profraw"
cargo test && grcov . -s . --binary-path ./target/debug/ -t html --branch --ignore-not-existing -o ./target/debug/cove
rage/

行为准则

请注意，本项目以贡献者行为准则发布。通过参与本项目，您同意遵守其条款。