#path #symlink #parent #safe #extension #presence

real_parent

符号链接安全路径扩展,用于父目录

4 个版本 (破坏性更新)

0.4.0 2024 年 6 月 27 日
0.3.0 2024 年 6 月 25 日
0.2.0 2024 年 5 月 27 日
0.1.0 2024 年 5 月 22 日

文件系统 中排名 #370

Download history 14/week @ 2024-05-16 250/week @ 2024-05-23 34/week @ 2024-05-30 3/week @ 2024-06-06 199/week @ 2024-06-20 227/week @ 2024-06-27 4/week @ 2024-07-04

每月下载量 265

MIT/Apache

16KB
177

real_parent

提供包括 real_parent 在内的路径扩展方法,该方法在存在符号链接的情况下是安全的。

需要注意的是,Path::parent 在存在符号链接的情况下会返回错误的结果,因此广泛使用了 Path::canonicalize 来缓解这个问题。然而,这种方法也有一些不便利之处(见下文)。

此 crate 的目标是用 PathExt::real_parent 的延迟调用替换对 Path::canonicalize 的急切和早期调用。

通过这种方式,用户对文件系统的首选和自然视图得到保留,并且父路径将在即时基础上正确解析。

广泛的 测试 是各种边缘情况行为的最佳文档。

理由

标准库方法 Path::parent 在存在符号链接的情况下不安全。有关背景信息和全面分析,请参阅 Plan 9 论文 正确处理点号

到目前为止,Rust 社区广泛依赖 Path::canonicalize 来缓解这个问题。虽然这种方法避免了路径损坏,但它产生了所有路径都变成绝对路径的讨厌结果,并将符号链接解析为其底层的物理路径。

考虑到符号链接部分是为了提供文件系统的抽象视图而存在的,因此,急切地将符号链接解析为其物理路径可能会被视为违反封装原则。也就是说,用户可能更愿意以符号链接而不是绝对物理路径的方式来处理他们的文件系统。相对于绝对路径,更喜欢相对路径的好处在于,它可以独立于文件系统中的绝对位置。

两个场景说明了这个问题。

Nix

Nix,特别是 Nix Home Manager,大量使用指向 Nix 商店的符号链接,而所有软件及其配置都安装在该商店中。

例如

> ls -l ~/.config/nushell/*.nu | select name type target
╭───┬─────────────────────────────────────┬─────────┬──────────────────────────────────────────────────────────────────────────────────────────╮
│ # │                name                 │  type   │                                          target                                          │
├───┼─────────────────────────────────────┼─────────┼──────────────────────────────────────────────────────────────────────────────────────────┤
│ 0 │ /home/sjg/.config/nushell/config.nu │ symlink │ /nix/store/vjx9vvdq2nqiz0dmqly9la8mqyz2lcnr-home-manager-files/.config/nushell/config.nu │
│ 1 │ /home/sjg/.config/nushell/env.nu    │ symlink │ /nix/store/vjx9vvdq2nqiz0dmqly9la8mqyz2lcnr-home-manager-files/.config/nushell/env.nu    │
│ 2 │ /home/sjg/.config/nushell/plugin.nu │ file    │                                                                                          │
╰───┴─────────────────────────────────────┴─────────┴──────────────────────────────────────────────────────────────────────────────────────────╯

更便于避免如此急切地将这些底层的 Nix 商店路径暴露给用户。

GNU Stow

GNU Stow 是一个符号链接农场管理器。它通常用于管理用户配置文件或 /usr/local

使用 GNU Stow 会导致大量的符号链接农场,文件看起来像是在彼此相邻的知名目录中存在,而实际上它们是文件系统各个位置的符号链接。

支持的平台

real_parent 在所有平台上运行,但在 Windows 上有以下注意事项。

  • 由于测试创建符号链接,要在 Windows 上运行测试,需要以管理员身份运行 🤯

  • Windows 上的符号链接行为很尴尬,因此在该平台上必须禁用一些测试

在 Windows 上隔离导致符号链接边缘案例中奇怪失败的原因超出了作者的 Windows 平台专业知识以及兴趣。欢迎在此领域提交拉取请求。然而,请注意,标准库中的 Path::canonicalize 也可能在这些边缘案例中失败。

测试

测试既练习了相对路径和绝对路径,包括 Windows 上的 UNC 路径,尽管这一点在测试用例数据中并不明显。

要查看所有测试的路径,使用 --nocapture 运行测试,并查找包含 verified 的行,例如在 Nushell 中。

> cargo test -- --test-threads=1 --nocapture | lines | find verified | to text

许可证

许可协议为以下之一

任选其一。

贡献

除非您明确声明,否则您有意提交的任何贡献,根据 Apache-2.0 许可证定义,均应作为上述双许可,不附加任何其他条款或条件。

无运行时依赖