硬链接的用例？

Question

在什么情况下会希望使用硬链接而不是软链接？我个人从未遇到过我想在软链接上使用硬链接的情况，而且我在搜索网络时遇到的唯一用例是对相同文件进行重复数据删除。

Answer 1

除了在另一条评论中提到的备份使用，我相信它也包括 BTRFS 卷上的快照，硬链接超过软链接的用例是标签排序的文件集合。（不一定是创建集合的最佳方法，数据库驱动的方法可能更好，但对于相当稳定的简单集合，这还不错。）

一种媒体收藏，其中所有文件都存储在一个平面目录中，并根据各种标准分类到其他目录中，例如：年份、主题、艺术家、流派等。这可以是个人电影收藏，也可以是商业工作室的集体作品。基本上完成了，文件被保存，不太可能被修改和排序，可能通过链接到多个位置。

请记住，“原始”和“复制”的概念不适用于硬链接：文件的每个链接都是原始的，没有通常意义上的“复制”。然而，对于用例的描述，这些术语模仿了行为的逻辑。

“原件”保存在“目录”目录中，排序后的“副本”硬链接到这些文件。排序目录上的文件属性可以设置为 r/o，以防止对文件名和排序结构的任何意外更改，而目录目录上的属性可以设置为 r/w，允许根据需要对其进行修改。（这种情况是音乐文件，其中一些播放器尝试根据嵌入在媒体文件中的标签、用户输入或互联网检索来重命名和重新组织文件。）此外，由于“复制”目录的属性可能与“原始”目录，排序结构可以提供给组或世界，访问受限，而主“目录”只能由主要用户访问，具有完全访问权限。但是，文件本身在指向该 inode 的所有链接上始终具有相同的属性。（可以探索 ACL 来增强它，但不是我的知识领域。）

如果原始文件被重命名或移动（例如，单个“目录”目录变得太大而无法管理），硬链接仍然有效，软链接将被破坏。如果移动“副本”并且软链接是相对的，那么软链接将再次被破坏，而硬链接则不会。

注意：当涉及软链接时，不同工具如何报告磁盘使用情况似乎不一致。然而，对于硬链接，它似乎是一致的。因此，将目录中的 100 个文件分类为一组“标签”，很容易就有 500 个链接的“副本”。（对于照片集，比如日期、摄影师和平均 3 个“主题”标签。）例如，Dolphin 会将其报告为 100 个文件用于硬链接，如果使用软链接则为 600 个文件。有趣的是，无论哪种方式，它都会报告相同的磁盘空间使用情况，因此它看起来像是用于软链接的大量小文件集合，以及用于硬链接的少量大文件集合。

对这种用例的一个警告是，在使用 COW 的文件系统中，修改“原始”可能会破坏硬链接，但不会破坏软链接。但是，如果目的是拥有主副本，在编辑、保存和排序之后，COW 不会进入场景。

Answer 2

硬链接对于您不想将两个文件的存在联系起来的情况很有用。考虑一下：

touch a
ln -s a b
rm a

现在b没用了。（这些步骤可能相距甚远，由不同的人完成，等等。）

而使用硬链接，

touch a
ln a b
rm a

b 仍然存在且正确。

Answer 3

单个程序可能会根据其启动的名称更改其行为：

$ ls -li `which pgrep` `which pkill`
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pgrep
208330 -r-xr-xr-x  2 root  bin  19144 Jul 26  2016 /usr/bin/pkill

源中的哪一个是通过类似的方式决定的

if (strcmp(__progname, "pgrep") == 0) {
    action = grepact;
    pgrep = 1;
} else {
    action = killact;

尽管确切的细节会因所涉及的操作系统和语言而异。

这允许（大部分）相同的代码不必编译成两个（大部分）相同的二进制文件。请记住，Unix 可以追溯到磁盘空间非常昂贵的日子，尽管根据 APUE 第 4 章中的 Stevens 的说法，符号链接是在 BSD4.2 (1983) 中实现的，以取代硬链接的各种限制。检查符号链接名称是否用作程序名称的测试程序可能如下所示：

#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
    printf("called as '%s'\n", *argv);
    exit(0);
}

并通过以下方式测试：

$ cc -o myname myname.c 
$ ln -s myname alias
$ ./myname
called as './myname'
$ ./alias
called as './alias'
$ 

Answer 4

当我的 P2P 软件完成下载某个文件时，该文件被放置在特定目录中。下载的文件几乎不需要编辑。常见的情况是我在需要文件所在的不同目录中创建硬链接。

好处：

• 即使我rm或mv“复制”，我仍然像我应该的那样在 P2P 网络中共享文件。
• 该文件也在我需要它的路径上；大多数这样的地点是不共享的。
• 我可以rm“原始”停止共享文件；此操作不会影响所需位置的“复制”。
• 我的磁盘空间只使用了一次。

要点：如果我事先知道我rm首先要哪个文件，我可能会使用符号链接。但我永远不知道。

Answer 5

文件系统是一种简单而有效的组织和分类文件的方式（这是它们存在的主要原因）。硬链接在这方面提供了更高程度的灵活性。

如前所述，在处理硬链接时没有原始和副本的概念，所有目录条目（硬链接）只是对文件存在的引用（指向其 inode）而没有优先级，因此也没有损坏的硬链接。 .

所以这里有一些硬链接参与但软链接不参与的用例：

1. 想象一下，你有一个电影、音乐或其他媒体的集合，并希望应用不同的分类标准，比如在一个分支中按艺术家分类的歌曲（每个艺术家都有自己的子目录）；按另一个分支中的流派（每个在不同的子目录中）等等。仍然不想复制文件，也不想决定将“原始”放在哪里，这样您就可以自由地重新分类而不必“管理”并在移动时重新链接文件，以避免链接断开。

2. 另一个原因是避免浪费存储空间，这将需要具有同一文件的多个副本，但允许chroot系统调用受益于“主”文件系统根目录中的文件子集（符号链接永远不能从外部引用文件在chroot沙箱中，即使他们有相对路径）。

3. 硬链接存在的另一个非常重要但很少提及的原因是..子目录。该..目录实际上是（在大多数UNIX FS的实现）硬链接到父目录，没有硬链接这有一个完全不同的方式来实现，而硬链接的存在使得这个非常容易实现。

Answer 6

需要硬链接的非常常见的真实示例：

git clone --reference <repository>

这是从本地 Git 存储库克隆的，几乎为零复制。它不是复制目标文件（Git 用于其“数据库”的不可变文件），而是简单地将它们硬链接。

任何 repo 都可以删除一个对象，但 inode 对 repos 的其余部分保持有效。如果一个对象从所有存储库中删除，它就会从磁盘中删除。硬链接是一个非常强大且快速的解决方案。在 CI 服务器中很常见。

有一个非硬链接版本：git clone --shared <repository>. 然而，这是善变的并且有更多的警告，因为每个人都在同一个目录上工作。