☰

我们应该如何理解`/proc/pid/fd`下的符号链接？

tag-icon • tag-icon linux symlink proc inode
我们应该如何理解`/proc/pid/fd`下的符号链接？

它们看起来更像是索引节点的链接，而不是路径的链接。readlink()调用进程根目录中 inode 的规范路径对他们来说意味着什么？当进程尝试打开它们时会发生什么，是否会为索引节点创建新的打开文件描述？

答案1

readlink() 对他们意味着什么，调用进程根目录中 inode 的规范路径？

对于常规文件，链接文本似乎与打开文件的路径相关，例如：

$ echo foo > abba
$ ln abba acdc
$ cat >> abba & 
[1] 12312
$ ls -l /proc/12312/fd/1
l-wx------ 1 foo users 64 Feb 19 15:19 /proc/12312/fd/1 -> /tmp/abba

重命名该名称会更改显示的路径：

$ mv abba qwerty
$ ls -l /proc/12312/fd/1
l-wx------ 1 foo users 64 Feb 19 15:19 /proc/12312/fd/1 -> /tmp/qwerty

与删除它一样：

$ rm qwerty
$ ls -l /proc/12312/fd/1
l-wx------ 1 foo users 64 Feb 19 15:19 /proc/12312/fd/1 -> /tmp/qwerty (deleted)

虽然通过链接打开文件仍然会发现索引节点有问题：

$ echo testtest > /proc/12312/fd/1
$ cat acdc
testtest

对于非常规文件，它显示 inode 类型（例如管道或套接字）和 inode 编号，这可能在某处可见/proc（例如/proc/net/tcp对于 TCP 套接字显示 inode 编号）。

当进程尝试打开它们时会发生什么，是否会为索引节点创建新的打开文件描述？

这是我的印象。我想我已经在 unix.SE 上看到过有关此内容的帖子，但我还没有看到任何“官方”文档。该行为绝对是独立文件描述的行为；不久前，我在 Stackoverflow 上的这个答案中编写了一个程序来测试：复制文件描述符并独立地搜索它们

相关内容