一、问题来源如图：
在阅读原文的时候我产生如下疑问：
文中说“因此用户 A 不能删除此文件，只是将该文件的 count 减 1, 然后删除自己目录中的相应目录项。用户 B 仍可以使用该文件。 ”，那用户A删除自己目录中的相应目录项后，此时文件主（文件的所有者）是谁呢？是用户B吗？
二、分析：用户 A 删除操作后的状态演变
1、 初始状态（共享中）
物理层：磁盘上存在一个 Inode（设为 #999），其
i_uid为 User A（创建者），i_nlink为 2。逻辑层：
User A 的目录项：
A_file-> Inode #999User B 的目录项：
B_file-> Inode #999
所有权归属：Inode #999 的
i_uid字段明确记录为 User A。虽然 User B 有访问路径，但所有权属于 User A。
2、 动作：用户 A 执行删除（unlink）
用户 A 决定不再需要该文件，执行rm A_file。此处不仅是简单的删除，而是触发了unlink()系统调用。该调用的执行逻辑如下：
权限检查：内核检查 User A 是否对User A 的目录拥有写权限。注意，删除文件本质上是修改目录的内容（移除列表项），因此检查的是目录的权限，而非文件的权限 。
移除目录项：内核从 User A 的目录数据块中抹除
A_file这一条目。此时，User A 失去了对 Inode #999 的访问入口。递减计数：内核锁定 Inode #999，将其
i_nlink值从 2 减至 1。生存判定：内核检查
i_nlink的新值。判定逻辑：
if (i_nlink == 0)则回收 Inode 和数据块；else则保留。当前结果：由于 Count = 1，内核仅仅更新 Inode 的
ctime（状态变更时间），并释放锁。文件数据和 Inode 结构保持原样。
3、 终态分析：所有权归属
此时，User A 的目录中已经没有该文件了，文件只存在于 User B 的目录中。关键问题是 ：User A 删除了自己的入口，文件所有者会变成 User B 吗？
结论：不会。
解析：
Inode 的持久性：
unlink操作仅仅修改了i_nlink计数器。它绝不会触碰i_uid（所有者 ID）或i_gid（组 ID）字段。在计算机科学中，未被修改的数据保持原值。因此，Inode 中的所有者信息依然是 User A 。所有权转移的机制缺失：UNIX 文件系统没有设计“自动过户”机制。所有权的变更（Change Ownership）是一个特权操作，必须通过
chown系统调用显式执行。系统不会因为某人删除了一个链接，就自作主张地将文件过户给另一个人。对等性悖论：如果删除链接会导致所有权转移，那么假设有 User A, B, C 三人共享。A 删除了，所有权该给 B 还是 C？由于 B 和 C 的链接是对等的，系统无法做出逻辑判断。因此，所有权必须保持不变，即仍属于最初的创建者 A。
因此可以回答图中的疑问：文中提到“用户 B 仍可以使用该文件”。此时，User B 访问的是 Owner 为 User A 的文件。User B 能否读取或写入，完全取决于 User A 当初设置的RWX权限。如果 User A 设置了“仅所有者可写”，那么 User B 即使是当前唯一的链接持有者，也只能读，不能写。
三、架构背后的安全模型与配额逻辑
理解了“所有权不变”的技术事实后，我们需要探究其背后的设计合理性。为什么操作系统不设计成“谁剩最后谁拥有”？这涉及到 UNIX 的多用户安全模型和资源配额（Quota）管理。
1、 磁盘配额（Disk Quota）的结算
在多用户服务器上，系统管理员通常会限制每个用户的磁盘使用量（例如 User A 只能用 10GB）。配额的计算是基于 Inode 的i_uid字段进行的 。
场景推演：如果 User A 创建了一个 5GB 的大文件，硬链接给 User B。
当前状态：该文件占用 User A 的 5GB 配额。
假设所有权转移：如果 User A 删除链接后，所有权自动变为 User B，那么该文件的 5GB 占用量将瞬间计入 User B 的配额。
恶意攻击向量（配额炸弹）：
User A 创建巨型垃圾文件。
User A 诱导 User B 创建硬链接（或者 User A 如果有权限写 B 的目录，直接硬链接过去）。
User A 删除自己的链接。
结果：User B 的磁盘配额被莫名其妙地占满，导致服务拒绝。User A 成功释放了自己的空间并攻击了 B。
为了防止这种“配额嫁接”攻击，UNIX 坚持“谁创建，谁负责”（除非显式转让）的原则。即使 User A 删除了链接，只要文件还存在（被 User B 引用），这个文件占用的磁盘空间依然算在 User A 的账上。这被称为“僵尸文件”或“孤儿所有权”现象——文件存在，但所有者已经没有路径访问它了，却还要为它付账。
2、 权限模型的稳定性
文件的权限（Permission Bits）也是存储在 Inode 中的。如果所有权自动变更，安全边界将崩溃。 例如，User A 创建了一个包含敏感数据的脚本，权限设为700（仅自己可见）。User A 将其硬链接到公共目录以便临时使用。使用后 User A 删除了公共目录的链接。如果此时所有权转移给了系统中的其他用户（假设存在某种竞态条件），那么敏感数据就可能泄露。保持所有权为 User A 确保了无论文件在哪里被访问，访问控制列表（ACL）始终如一。
四. 用户 B 的操作困境与解决方案
在 User A 删除链接后，User B 此时持有的是一个“属于 User A 的文件”。这对 User B 意味着什么？
1、读写权限受限
User B 对该文件的操作权限受到 Inode 中i_mode字段的严格限制：
如果 User A 设置了
chmod 644（所有者读写，他人只读）：User B 只能读取文件，无法修改。即使 User B 想删除这个文件来释放空间，他也只能删除自己目录下的这个“入口”，而不能修改文件内容。如果 User A 设置了
chmod 666（全员可写）：User B 可以修改文件内容。任何修改都会直接作用于磁盘上的数据块。如果 User A 之后通过某种手段（如debugfs或恢复工具）找回了文件，会看到 User B 修改后的版本。
2、编辑器的行为差异（Edit vs Replace）
这是硬链接使用中最容易产生误解的地方。当 User B 试图用文本编辑器（如 Vim, Nano, VS Code）编辑这个文件时，结果取决于编辑器的保存策略 ：
策略一：就地写入（In-place Edit）
编辑器打开文件，读取内容，用户修改。
保存时，编辑器打开原路径，将新数据写入原 Inode。
结果：Inode 编号不变，所有者依然是 User A。User B 必须有写权限才能成功。
策略二：原子替换（Atomic Save / Unlink-and-Create）
编辑器写入一个临时文件（新 Inode，所有者为当前操作者 User B）。
编辑器执行
rename(temp_file, original_filename)。这会隐含地执行unlink原文件，并用新文件取代之。结果：原 Inode（属于 User A）的引用计数减为 0，被系统回收。目录项现在指向一个新的 Inode，这个新 Inode 由 User B 创建，因此所有者变成了 User B。
结论：如果 User B 使用“原子替换”策略的编辑器修改文件，表面上看起来所有权变了，但实际上是 User B 悄悄地把 User A 的旧文件替换成了一个内容相同的新文件。旧的链接关系已经被切断。
