rus*_*ush 14 filesystems symlink
我的意思是当某个进程想要读取符号链接时发生了什么？在读取甚至写入过程中更改符号链接时会发生什么？
例如：我有 2 个巨大的、类似的 100G 文件/mnt/1和/mnt/2. /mnt/1可通过符号链接获得/home/user/file。一些程序A开始阅读/home/user/file。过了一会儿，链接从/mnt/1到/mnt/2，但A仍在读取文件。
程序是否缓存了绝对路径？
它会失败并出错，因为符号链接已更改，还是会正常工作，就像什么也没发生一样？
如果/home/user/file链接到块设备（例如 2 个复制的 iSCSI 磁盘），它会有所不同吗？
Kev*_*vin 10
符号链接指向文件系统中真实文件 ( inode )的名称。当系统解析该符号链接以查找实际文件并打开它时，它会查找并使用文件的 inode。那时，您用来访问文件的路径无关紧要。操作系统不缓存的内容，它通过其 inode 从文件中读取。据我了解，您可以通过硬链接开始读取文件并删除该硬链接（只要该文件仍是从其他地方链接的），只要文件已解决，就不会导致问题（名称字符串-> inode）。
一个符号链接是包含一个小文件位置的目标文件（即路径和文件名），在表明它是一个符号链接的目录项的标志。
当您打开符号链接时，操作系统将按照该位置查找目标文件。如果目标本身是一个符号链接，它也会跟随它的位置 (1)(2) 直到该位置指向一个不是符号链接的文件（我们称之为FinalFile）。然后，OS取得索引节点的的FinalFile（i节点包含这样的修改时元数据并且也具有一个指向该文件的数据）。最后打开FinalFile的 inode 。从现在开始，进程使用该 inode 来读/写文件。结果更改符号链接名称或路径，删除符号链接，更改FinalFile的路径或名称，甚至删除FinalFile(3) 对过程没有影响；它仍在从同一个 inode 读取。
在大多数情况下，符号链接上的文件数据操作会影响FinalFile（例如，读取和写入符号链接将从/写入FinalFile），但也有例外：readlink()系统调用读取符号链接本身的内容。
另一方面，文件元数据操作（如重命名或删除）通常会影响符号链接。但这里也有例外：lstat()系统调用类似于stat()，除了它返回符号链接本身而不是FinalFile (2) 的信息。
(1) 如果符号链接中的位置是相对路径，则级别数会受到限制，并且事情会变得更加复杂。
(2) Read symlink(7): 符号链接处理了解更多细节。man 7 symlink
(3)rm命令或unlink()系统调用不会物理删除文件。它删除指向文件 inode 的目录条目。只有当文件本身被删除两者一）有引用它的索引节点和b）没有进程打开文件没有更多的目录条目（硬链接）。