☰

“ln -L”(--logic) 有什么用处？

tag-icon • tag-icon linux hardlink ln proc
“ln -L”(--logic) 有什么用处？

我可以在 ln 手册页中看到：

   -L, --logical
          make hard links to symbolic link references

我读到过一些文章，ln -L可以使用/proc文件系统重新链接已删除但仍处于打开状态的文件。例如：

ln -L /proc/1234/fd/12 /tmp/my-file

但我得到的是ENOENT：没有这样的文件或目录。如果我尝试不同的文件系统，我得到的是无效的跨设备链接。

如果我不能用它ln -L来恢复已删除的文件，那么它可以用来做什么？

答案1

GNU 实用程序主要通过info页面来记录。GNU ln 信息页面：

‘-L’
‘--logical’
    If -s is not in effect, and the source file is a symbolic link,
    create the hard link to the file referred to by the symbolic link,
    rather than the symbolic link itself.

因此，这只是取消引用作为源参数给出的符号链接。

答案2

好吧，这是一个对新手更友好的答案......

事先了解一些基础知识

UNIX/Linux 系统上文件存储的简单视图是：有一个目录条目，其中包含您看到的名称ls -l以及 Inode 编号（您可能会看到ls -i）。 Inode 包含您的数据在文件系统上存储的实际信息（以及所有权、权限、必要时更多的 Inode 等信息）：

（是时候享受一下 UTF-8 的乐趣了... ;-) ）

简单视图：

┌─────────────────┐    ┌───────┐    ┌─────────────┐
│ directory entry │ ─► │ Inode │ ─► │ data blocks │
└─────────────────┘    └───────┘    └─────────────┘

现在来看一下硬链接和符号链接之间的区别：

硬链接只是一个指向与现有 Inode 相同的 Inode 的目录条目，而符号链接只是一个包含另一个文件名称的特殊文件（如果路径名足够小，则直接存储在 Inode 中）。这就是为什么

  • 指向同一文件的硬链接不能具有不同的文件访问权限（因为这些权限存储在 Inode 中）
  • 硬链接必须位于同一文件系统内

扩展简单视图

 ┌─────────────────┐   
 │    hard link    │ ───────┐
 └─────────────────┘        ▼
 ┌─────────────────┐    ┌───────┐    ┌─────────────┐
 │  example_file   │ ─► │ Inode │ ─► │ data blocks │
 └─────────────────┘    └───────┘    └─────────────┘
          ▲
          └───────────────────────┐
                                  │
 ┌─────────────────┐    ┌─────────┴──────────┐
 │  symbolic link  │ ─► │ filename reference │
 └─────────────────┘    └────────────────────┘

现在回到缺席-L的选项-s：它允许您创建一个硬链接一个文件，其中符号链接指向（如上例中的“硬链接”）。

为什么这有助于恢复已被删除但仍被打开的程序使用的文件？

当然，这种行为非常依赖于实现，并且您的里程可能会因所有 UNIX/Linux 平台而异，但我会尝试解释它是如何可以工作：

当文件被删除时（比如说通过室(1)）所调用的系统调用始终是取消链接(2). 它删除目录条目并将链接计数器（在 Inode 内维护）减少一。

如果链接计数器达到零，则操作系统需要进行清理（实际上释放 inode 指向的数据块，然后释放 Inode 本身）。但如果文件仍然打开，则此任务通常会被推迟，直到使用 inode 的程序终止。

如今，大多数 UNIX 系统都维护着一个/proc文件系统层次结构，人们可以在其中查找对打开文件的引用，这些文件（惊喜！）符号链接。假设找到了正确的条目，ln -L 可能帮助重新创建到 inode 的链接，再次增加链接计数器，从而防止操作系统删除 inode（如果幸运的用户足够快并且程序仍在运行）。

注意：为了使其正常工作，新链接的位置必须与原始链接位于同一文件系统上！

最后的例子

 ┌─────────────────┐   
 │   rescue_link   │ ───────┐
 └─────────────────┘        ▼
 ┌─────────────────┐    ┌───────┐    ┌─────────────┐
 │ *** removed *** │    │ Inode │ ─► │ data blocks │
 └─────────────────┘    └───────┘    └─────────────┘
          ▲
          └───────────────────────┐
                                  │
 ┌─────────────────┐    ┌─────────┴──────────┐
 │ /proc/bla/fd/n  │ ─► │ filename reference │
 └─────────────────┘    └────────────────────┘

最后的话

有很多因素可能会阻止正确创建链接，而且这在很大程度上取决于符号链接本身的实现方式，我不得不承认：我非常怀疑它是否适用于许多 UNIX 变体 - 但也许有志愿者愿意花一些时间来测试这个？

相关内容