目录
[硬链接 vs 软链接：五大维度完整对比](#硬链接 vs 软链接：五大维度完整对比)
[硬链接的链接计数为 0 时文件数据一定会被删除吗？](#硬链接的链接计数为 0 时文件数据一定会被删除吗？)
[访问控制列表（ACL）和 Linux 的 rwx 有什么区别？](#访问控制列表（ACL）和 Linux 的 rwx 有什么区别？)
核心要点：
- 文件共享的关键前提是"系统中只有一份文件数据"------多个用户各复制一份不叫共享，叫备份
- 硬链接的本质是多个目录项指向同一个索引结点（inode），删除任一链接不释放数据，只有最后一个目录项删除且引用计数归零时才真正删除
- 软链接（符号链接）是独立的文件类型，存放的是目标路径字符串，删除目标文件后链接失效（悬空链接）
- 三种保护机制的信任模型各不相同：口令靠"秘密"、加密靠"算法"、访问控制靠"规则"，三者可以组合使用
- 408 考研高频考点："硬链接不能跨文件系统"和"软链接删除目标后失效"几乎每年必有相关题目
文件共享与保护：从硬链接到访问控制矩阵
一个文件，多个用户：共享和复制有区别吗？
操作系统的文件共享（File Sharing）功能让多个用户共用同一份文件数据。这里的关键词是"同一份"。
假设三个用户都需要访问 /home/shared/reference.pdf。如果每个用户都在自己的目录下复制（copy）一份，这是三份独立的数据------A 修改了自己的副本，B 和 C 完全看不到。这不叫共享，只是复制。真正的共享意味着：无论通过谁的目录访问，读写的都是同一个物理文件。A 修改了内容，B 和 C 立即能看到变化。
引用 王道书中特别强调：文件共享的核心标志是共享引用计数（硬链接的 count > 1，或软链接的目标文件被多个用户间接访问）。
硬链接：基于索引结点的零额外开销共享
共识 回顾一下索引结点（Index Node, inode）：为了精简目录项，文件系统将"文件名"之外的所有元信息（大小、时间戳、物理块指针、权限等）抽离到 inode 中。目录项只剩两个字段------文件名 + inode 指针。
硬链接 （Hard Link）的思路极为简洁：让不同用户的目录项指向同一个 inode。
用户A的目录项: [文件名 "report.txt"] → [inode 指针 → inode #1024] ┐
├── 同一inode
用户B的目录项: [文件名 "共享/report.txt"] → [inode 指针 → inode #1024] ┘
↑ ↑
同一个inode count = 2引用 inode 中维护一个链接计数（link count / reference count）字段。每新增一个硬链接，count + 1；每删除一个，count - 1。当 count 降为 0 时，OS 才真正回收该文件所占的磁盘空间。
经验 这里有一个关键推论：删除一个目录项（unlink）不一定意味着删除文件数据 。只有当 count 归零时，物理块才被释放。这也是为什么 rm 命令删除硬链接时不会立即清除数据------它只是"断开"了一条链接。
硬链接的优点是几乎零额外开销------不需要新 inode，不需要新数据块，只是在目标目录中增加一条目录项。缺点是不能跨文件系统 （inode 编号只在同一个文件系统内有效），也不能给目录创建硬链接（防止形成目录环，导致文件系统遍历时出现死循环）。
软链接（符号链接）：灵活但有额外查找开销
共识 软链接 （Symbolic Link / Symlink）采用另一种策略：创建一个新的文件 （新 inode），该文件的内容不是数据，而是一个路径字符串（目标文件的路径）。
当用户通过软链接访问时，OS 发现这个文件是符号链接类型，读取其中存储的路径字符串，然后沿着该路径重新查找目标文件。
经验 这好比"快捷方式"的概念------桌面上放了一个快捷方式，双击它实际打开的是另一个位置的真实文件。在 Linux 下 ln -s target.txt link.txt 创建的正是一个软链接文件。
软链接的优势很明显：
- 可以跨文件系统（路径是字符串，不受 inode 编号约束）
- 可以链接目录（路径指向目录，不会形成目录环------因为文件系统遍历时可以识别符号链接并跳过）
- 创建时不需要目标文件存在（路径字符串只是存着，访问时才验证）
但代价也同样明显：每次通过软链接访问，需要额外解析路径字符串，多了一次 I/O 开销。而且，一旦目标文件被删除（inode 释放），软链接就变成了悬空链接（Dangling Link）------路径还在，但指向的地方没有文件了。
硬链接 vs 软链接：五大维度完整对比
共识 以下是考试和工程中都需要掌握的五个对比维度：
| 对比维度 | 硬链接 | 软链接（符号链接） |
|---|---|---|
| 本质 | 多个目录项指向同一 inode | 新文件存储目标路径字符串 |
| 是否新建 inode | 否（共享已有 inode） | 是（符号链接自身是一个文件） |
| 跨文件系统 | 不支持（inode 仅在本 FS 内唯一） | 支持（路径是字符串） |
| 链接目录 | 不支持（防止目录环） | 支持 |
| 目标删除后 | 数据不释放（count > 1），链接仍有效 | 链接变成悬空，访问报错 |
| 额外访问开销 | 无 | 需要解析路径字符串 |
| 共享计数 | inode 中 count 字段 | 无共享计数概念 |
经验 408 考研中有一道高频题："下列关于硬链接和软链接的说法，正确的是？"------几乎所有错误选项都围绕"硬链接可以跨文件系统""软链接共享 inode""可以为目录创建硬链接"这三个方向设计。
口令保护：简单但不够安全的方案
共识 口令保护（Password Protection）是最直接的保护方式------为文件设置一个"口令"字符串，用户访问文件前必须输入口令，OS 将其与 FCB 或 inode 中存储的口令对比。
引用 王道书指出：口令的优点在于空间开销小 （几十字节）和验证速度快（字符串比较）。但缺点同样尖锐------口令以明文形式存放在系统内部，任何能访问 FCB 的管理员或进程理论上都能获取。
这就像把钥匙挂在门边------知道位置的人都能拿得到。
经验 实际工程中，口令保护通常不作为唯一防线，而是与文件系统权限（如 Linux 的 rwx）配合使用。更常见的是将口令验证"前置"到登录阶段（用户登录时验证密码，之后用 UID 控制所有文件访问），而非为每个文件单独设口令。
加密保护：即使文件被盗也无法被解读
共识 加密保护（Encryption Protection）比口令保护更安全：对文件的原始数据使用某种密码（cipher）进行加密变换，只有拥有正确解密密钥的人才能还原出原始数据。
引用 教材中以异或（XOR）加密为例说明基本原理：
原始数据: 0 0 1 0 1 0 0 1
密钥: 0 1 0 0 1 0 1 0
XOR 结果: 0 1 1 0 0 0 1 1 → 这就是加密后的密文解密时，将密文与同一密钥再做一次异或，即可恢复原始数据（XOR 的对称性：A ⊕ B ⊕ B = A）。
经验 加密保护的信任基点与口令保护完全不同：口令保护的弱点在于"口令存在系统内部"；加密保护的密钥由用户自行保管，文件数据即使被他人获取也只是一堆无意义的乱码。但代价是每次读写都需要加解密运算，有额外 CPU 开销。
共识 实际上，现代文件系统（如 APFS、NTFS 的 EFS、ext4 的 fscrypt）使用的加密方案远比 XOR 复杂，通常采用 AES-256 等工业标准，但基本原理（对称加密/非对称加密 + 密钥管理）是一致的。
访问控制：从矩阵到列表的精简演化
共识 访问控制矩阵（Access Control Matrix）是最通用的保护模型：用一个二维矩阵表示系统中每个用户对每个文件的访问权限。
file1 file2 file3 file4
user_A rwx r-- rw- ---
user_B r-- rwx --- rwx
user_C --- rw- rwx r--每一行是一个用户的访问控制列表（Access Control List, ACL），记录了该用户对所有文件的权限。但实际系统中用户数和文件数都很大，矩阵会非常稀疏（大量"---"），存储浪费严重。
共识 实际采用的精简策略是按列存储 （以文件为单位）：每个文件的 ACL 只记录对该文件有访问权限的用户和对应权限，忽略"无权限"的用户。这样每个文件的 ACL 长度只与有权限的用户数成正比，而非总用户数。
经验 Linux 的 rwx（所有者的 rwx + 同组用户的 rwx + 其他用户的 rwx）本质上是 ACL 的一种极度精简形式------将用户分为三类（owner / group / others），每类 3 bit 权限位。
引用 在 Unix/Linux 系统中，"文件控制块"（inode）中维护的权限位（9 bit rwx）实际上就是一种硬编码的三分类 ACL。
三种保护机制的组合：没有银弹
共识 三种保护机制关注的安全威胁模型不同：
| 机制 | 防范的威胁 | 弱点 |
|---|---|---|
| 口令保护 | 未授权访问（需知道口令） | 口令存于系统内部，管理员可读 |
| 加密保护 | 数据泄露（即使文件被盗） | 加解密有 CPU 开销 |
| 访问控制 | 未授权访问（基于用户身份） | 依赖 OS 正确实现，不能防御物理访问攻击 |
经验 一个合理的设计是：访问控制决定"谁能打开文件"，加密决定"打开了能不能读懂"。两者互补------即使访问控制被绕过（如硬盘被盗），加密保护仍然有效。
FAQ
为什么硬链接不能跨文件系统？
因为硬链接共享 inode 编号，而 inode 编号只在同一个文件系统内唯一。文件系统 A 的 inode #1024 和文件系统 B 的 inode #1024 指向完全不同的文件。
软链接删除目标文件后会怎样？
软链接本身仍然存在（它是个独立文件），但访问时会报错"No such file or directory"------这种状态称为"悬空链接"（Dangling Link）。重新创建一个同名目标文件后，软链接即可恢复工作。
硬链接的链接计数为 0 时文件数据一定会被删除吗？
不一定。如果还有进程打开了该文件（文件已打开但目录项已删除），则文件数据在进程关闭之前不会释放。Unix 语义是：文件数据和 inode 的释放条件是引用计数归零 AND 无进程打开该文件。
访问控制列表（ACL）和 Linux 的 rwx 有什么区别？
Linux 的 rwx 是三分类（owner/group/others），每个文件只能为一个 group 设置权限。ACL 支持为任意多个用户和组分别设置不同权限，粒度更细。现代 Linux（支持 ACL 的 ext4/xfs）可以通过 setfacl / getfacl 命令管理 ACL。
口令保护和加密保护能同时使用吗？
可以，而且互补。例如：先用访问控制限制谁能打开文件，打开后发现内容是加密的，需要密钥才能解密。即使访问控制被绕过（如直接读磁盘），文件内容也是密文。
总结
文件共享的核心矛盾在于"如何让多个用户访问同一份数据而不会形成混乱"。硬链接用最少的元数据开销实现了共享（同一个 inode），但牺牲了跨文件系统和目录链接的能力；软链接靠路径间接层实现了最灵活的共享，但引入了额外查找开销和悬空链接风险。
文件保护的三种机制代表了三层安全理念：口令是"知道秘密才能进"、加密是"拿到数据也看不懂"、访问控制是"按身份规则放行"。三者叠加，才能构建可靠的文件安全体系。