符号链接和硬链接有什么区别?


Answers:


40

硬链接和软链接之间的语义不同,使它们适用于不同的事物。

硬链接:

  • 与其他目录条目没有区别,因为每个目录条目都是硬链接
  • 可以移动或删除“原始”,而不会破坏指向同一索引节点的其他硬链接
  • 仅在同一文件系统中可能
  • 权限必须与“原始”上的权限相同(权限存储在索引节点中,而不是目录条目中)
  • 只能用于文件,不能用于目录

符号链接(软链接)

  • 只需记录指向另一个文件路径的位置即可。(ls -l将显示符号链接指向的路径)
  • 如果原件被移动或删除,将损坏。(在某些情况下,实际上希望链接指向当前占据特定位置的任何文件)
  • 可以指向其他文件系统中的文件
  • 可以指向目录
  • 在某些文件系统格式上,符号链接可能具有与其指向的文件不同的权限(这是罕见的)

1
不错的清单。只是想补充一点,您也可以通过移动符号链接本身来断开相对路径符号链接。
2011年

4
“ [E]每个目录条目都是硬链接。” 这是我以前从未见过的极好点,但是我担心只是开始将他的头或头缠在链接周围的人不会明白这一点。对于处于这种情况的用户,这里有个提示:运行ls命令时看到的文件和目录的布局与其所代表的存储系统并不完全相同。硬链接是对存储系统上单个文件的引用。一个文件存储一次。阅读“ inodes”。
Mario

@Mario:是的。每个目录条目都将一个名称链接到一个索引节点。甚至删除了用于删除文件名的系统调用unlink(2)。“正常”文件(链接计数为1)只是一种特殊情况。如果有帮助,您可以将inode视为对象,将名称视为ref计数的指针(inode的链接数为reference-count)。
彼得·科德斯

1
您可以将符号链接视为带有名称的文本文件。由于文件的特殊标志,它被解释为符号链接。您知道的硬链接示例是...
Ned64

这是另一个答案,解释了为什么无法建立目录的硬链接。我发现此答案很有帮助,因为它更简洁,更易于阅读。
特雷弗·博伊德·史密斯

18

两种类型的链接的目的是提供一种使文件同时出现在两个位置的方法。这有很多用途。您要使用符号链接,十分之九。

符号链接或“符号链接”的工作方式与Windows快捷方式类似。符号链接的内容是指向文件/目录实际位置的指针。如果删除实际文件,则符号链接将变为“悬挂”,并且将不起作用。删除符号链接不会删除真实文件。您可以根据需要为单个文件设置尽可能多的符号链接(甚至其他符号链接)。

但是,与Windows不同,它们在文件系统级别而不是外壳程序或应用程序级别上工作,因此几乎所有应用程序都将按预期“跟随”符号链接。 ls -al可以用作查看符号链接“指向”何处的快速方法。

硬链接甚至可以在较低级别上使用。硬链接是文件的实际,物理上文件系统级的目录条目。从技术上讲,目录条目是一个硬链接,因此,每个文件在某个位置的目录中至少有一个硬链接。硬链接并不与其指向的文件分开。如果文件在不同目录中具有多个硬链接rm,则在所有硬链接都消失之前,使用类似的实用工具删除硬链接不会真正删除该文件。

我想不出通常甚至需要使用硬链接的情况,除非您有意防止文件被删除或者对分区或其他与文件系统相关的事情进行了一些怪异的低级工作。编辑:这个问题的其他答案中有很棒的主意!


而且,符号链接具有与普通文件类似的权限,但是操作系统不会查阅它们,而是查阅权限目标文件来决定行为。而且,不要做符号链接的循环链。很坏。
LawrenceC

3
真的很不好吗?会发生什么?我最能重现的激动是“太多级别的符号链接”错误消息。
mattdm 2011年

1
ls -l足以看到符号链接所链接的内容,a代表--all,请参见联机帮助页。即使符号链接在文件系统上起作用,也存在将符号链接用作文件而不是跟随符号的替代功能。
D4RIO 2011年

4
Windows快捷方式实际上与符号链接有很大不同:它们遵循其目标,并且它们也是常规文件。(Windows也有符号链接,但是使用它们并不多。)符号链接是纯文本的,只要您访问文件,就会读取目标文本。符号链接权限是否重要取决于操作系统和文件系统。
吉尔(Gilles)“所以,别再邪恶了”

AFAIK,符号链接文件的内容是符号链接指向的路径,在查看符号链接文件的大小时可以看到它:ln -s /home 1; ls -l 1显示符号链接1的长度为5个字节,而ln -s /usr/share/ 2; ls -l 2符号2的长度为11个字节。
丹尼尔·库尔曼2012年

13

硬链接对于基于磁盘的备份机制非常有用,因为您可以为每个备份使用完整的目录树,同时为未更改的文件共享空间-并且文件系统会跟踪引用计数,因此当最后一次引用时给定版本消失,因为由于空间原因备份已过期/已删除,因此会自动回收其使用的空间。出于相同的原因,某些邮件客户端还将它用于归档到多个文件夹的邮件。


5
也许基于磁盘的版本控制机制?如果您进行硬链接,则不是备份。如果原始文件损坏,则指向它的每个硬链接也将损坏。
D4RIO 2011年

1
想想增量备份系统,例如Apple的Time Machine。(显然,这些备份不是灾难恢复类型的备份,而是“糟糕,我无意中删除了该文件”备份。)增量备份中所有未更改的文件都硬链接在一起;更改文件后,下一个增量文件将复制它,而不是链接到前一个版本。
geekosaur 2011年

谢谢,然后增量备份系统与版本控制系统非常相似,这种方式= D
D4RIO 2011年

但是,增量备份机制如何保留文件的“旧”版本?1)创建备份A,将其与文件F进行硬链接;2)修改文件F;3)第二天创建了备份B ...好像我什么都没收到
Dmitry Pashkevich 2013年

3

硬链接只是对相同磁盘空间的引用,这就是“为什么”您不能硬链接其他文件系统中的某些内容。

符号链接是链接其他文件的文件(如Windows快捷方式),可能位于同一文件系统中,也可能不在同一文件系统中。

编辑:我将解释更多。每个存在的文件至少具有1个硬链接。硬链接是访问文件系统的索引节点内容的方式。您可以使用来获取文件的inode编号ls -i,并通过stat以下示例获取硬链接的数量:

$ stat plantilla-disenos.odt 
  File: «plantilla-disenos.odt»
  Size: 12367       Blocks: 32         IO Block: 4096   fichero regular
Device: 803h/2051d  Inode: 319875      Links: 1
Access: (0644/-rw-r--r--)  Uid: ( 1000/   d4rio)   Gid: ( 1000/   d4rio)
Access: 2011-02-11 21:36:19.000000000 -0300
Modify: 2010-03-02 23:27:28.000000000 -0300
Change: 2010-04-10 17:46:27.000000000 -0300

感谢@geekosaur提供此参考:

内核必须重新启动路径名到inode的转换(遍历目录树)以扩展符号链接,而硬链接都使用相同的inode。(从在传统Unix中执行此操作的内核函数的名称中,您经常会看到它被称为namei。)

这(编辑):

硬链接对于像Apple的Time Machine这样的基于磁盘的增量备份机制非常有用,因为您可以为每个备份拥有完整的目录树,同时共享未更改文件的空间-文件系统会跟踪引用计数,因此当由于空间原因而导致备份的过期/删除导致对给定版本的最后引用消失时,将自动回收其使用的空间。出于相同的原因,某些邮件客户端还将它用于归档到多个文件夹的邮件。

干杯


使用硬链接对性能有好处吗?或者,为什么您会使用硬链接而不是符号链接?
ripper234 2011年

内核必须重新启动路径名到inode的转换(遍历目录树)以扩展符号链接,而硬链接都使用相同的inode。(您经常会namei在传统Unix中从执行此功能的内核函数的名称中看到它被称为。)
geekosaur 2011年

@ ripper234:硬链接是节省磁盘空间的解决方案。您不需要了解进行符号链接的文件系统,但是您需要在创建符号链接之前进行思考,因为您可以创建循环或长解析路径,因此类似的功能stat将失败。
D4RIO 2011年

@geekosaur:我要向我添加您的答案,因为它非常有用
D4RIO 2011年

没问题。我实际上开始写它作为对您的评论,但评论太短了。
geekosaur 2011年

3

软链接指向另一个路径名。该路径名可能存在也可能不存在。在您访问符号链接之前,不会寻找该路径。如果在尝试访问该路径时不存在,则符号链接已损坏。

通过硬链接,您可以拥有一个具有多个名称的文件。您不能说其中之一是“真实”文件,而其他文件只是该文件的链接。他们都是平等的。没有像断开的符号链接那样断开的硬链接。

硬链接仅在单个文件系统中起作用。如果要链接到其他文件系统(例如,不同的分区或网络共享)上的文件,则必须使用软链接。

另一个很大的不同是删除链接文件时会发生什么。如果删除一对硬链接文件中的一个,然后创建一个具有相同名称的新文件,则将有两个单独的文件(链接消失了)。如果删除符号链接的目标并创建一个具有相同名称的新文件,则该链接将指向该新文件。


3

“硬”链接共享相同的索引节点

$ touch foo
$ ln foo foolink # Creates a hard  link
$ ls -li foo foolink
54996 -rw-r--r-- 2 bsd users 0 2011-12-11 09:06 foo
54996 -rw-r--r-- 2 bsd users 0 2011-12-11 09:06 foolink

如果我编辑foo或foolink,则只有一个文件,它将被更新。如果仅删除其中一个文件名,则索引节点和数据将保留,foolink将继续存在。

$ rm foo
$ ls -li foo foolink
ls: cannot access foo: No such file or directory
54996 -rw-r--r-- 1 bsd users 0 2011-12-11 09:06 foolink

如果要创建相同的文件,但是要使用“软”或符号链接,那么将有一个文件,一个索引节点和一个新文件,其自身的索引节点指向第一个。

$ touch foo
$ ln -s foo foolink # Create symlink
$ ls -li foo foolink
55029 -rw-r--r-- 1 bsd users 0 2011-12-11 09:11 foo
55033 lrwxrwxrwx 1 bsd users 3 2011-12-11 09:11 foolink -> foo

如果我编辑foo或foolink,仍然只有一个文件,它将被更新。

如果仅删除符号链接,则索引节点和数据将保持不变。如果删除foo,数据将消失,符号链接将保留,但指向不存在的文件。

$ rm foo
removed `foo'
$ ls -l foo foolink 
ls: cannot access foo: No such file or directory
lrwxrwxrwx 1 bsd bsd 3 2011-12-11 09:11 foolink -> foo

1
但是,实际的用例是什么?
ewwhite 2011年

1
一种用途,与“快捷方式”相同。另一种用途,在系统上具有多个版本的应用程序,允许安装,测试新版本,通过完整路径指定应用程序,而bin中的符号链接指向生产。测试完成后,将符号链接更改为新版本,对于具有版本相关代码的所有用户,将旧版本保留在原位。考虑一下perl,python等
。–

1
硬链接的实际用例。目前,在我的文件系统上,我在/ usr / share / zoneinfo中找到了大量的硬链接。想一想所有代表时区的命名文件,它们都与EST相同。我们没有冗余副本,从而节省了文件系统空间,并且在安装/删除软件包时无需安装/删除symlinks的管理开销即可简化软件包管理。即使删除一个,原始数据也会保留下来。抱歉,我没有时间进行更深入的解释。
bsd

1

硬链接是同一文件的其他目录条目。那意味着

  • 到文件的所有硬链接必须位于同一文件系统上(因为目录条目不能指向不同文件系统上的文件),但不一定位于同一目录中。
  • 原始目录条目和新的硬链接之间没有什么区别;从操作系统的角度来看,它们只是同一文件的两个目录条目。仅当所有硬链接都被删除时,文件才会被删除(此外,该文件仍然没有打开的进程)。
  • 如果移动/重命名“原始”文件,只要不将其移动到另一个文件系统,其他硬链接就不会受到影响。他们仍然指向同一文件。
  • 保存时,许多编辑器不会将新内容写入同一文件中,而是执行以下过程:

    1. 将新内容写入文件。
    2. 将旧文件重命名为备份名称(或者,如果不保留先前文件版本的备份,只需删除它)。
    3. 将新写入的文件重命名为上一个文件的名称。

    这种方案意味着到该文件的任何其他硬链接现在都不再指向当前文件,而是指向以前的版本(即使在编辑器删除旧文件的情况下也是如此,因为在Unix下,“删除”一个文件)仅表示删除其链接;仅当删除的链接是唯一的链接时,实际文件才会被删除)。

  • 由于硬链接直接指向文件,因此即使您无权访问该文件的原始位置,您也可以访问该文件(例如,因为您对原始条目所在的目录没有任何权限) 。决定访问的唯一权限是文件本身的访问权限(与文件关联,而不与链接关联;您不能对同一文件进行具有不同权限的硬链接),而路径的访问权限就是硬链接包含在其中(基本上是链接所在目录的执行权限,以及任何直接和间接的父目录)。

另一方面,符号链接存储另一个文件的路径名(文件的名称-或更确切地说,它的目录条目-可能包括其路径,例如/bin/shsubdir/foo.bar)。如果路径名是相对的,则始终相对于包含链接的目录进行解释。这意味着:

  • 符号链接可能引用不同文件系统上的文件(甚至是本身不支持硬链接或软链接(例如FAT)的文件系统)。

  • 如果原始文件被删除,则符号链接不会保留文件内容。除非存在指向同一文件的其他硬链接,否则文件内容将消失。然后,符号链接将悬空(即,引用与目录条目不对应的路径名)。另一方面,删除符号链接不会影响原始文件,因为它仅引用其路径名。

  • 如果原始文件被移动或重命名,则符号链接不会更新,但会悬空。如果移动符号链接,则仅当它包含相对路径时,它才会断开,并且该路径从新位置开始不再有效。

  • 如果原始文件被具有相同名称的新文件替换(如上述编辑器方案中所示),则该链接引用该新文件。

硬链接的大多数使用基本上是一种获得文件副本而不必两次存储文件内容的方法。如果不再更改文件,这将是最好的选择,否则很容易意外断开链接(请参见上面的编辑器方案)。当然,在某些情况下,您希望断开链接,例如保留多个备份:对于新备份中已更改的文件,您也不想更改旧备份中的副本。

通常,如果需要链接,将使用符号链接。一个示例是,当您将目录移至另一个分区(因为该目录已满)时,可以设置从旧位置到新位置的软链接,因此任何尝试访问该旧目录的程序都将而是在新位置访问它。硬链接是不可能的。但是,请注意,如果移动目录中的符号链接包含引出移动目录的相对路径,则它们可能会中断。


1

硬链接(仅文件)vs软链接(文件或目录)vs绑定(目录的硬链接)

阅读文章前查看此图像
(来源:freesoftwareservers.com

尽管daxelrod的回答很好地说明了这个问题,但我认为这种情况下的情况有很大的不同,特别是对于还不了解inode和复杂的Linux行话的初学者。

想到这一点,如果您从驱动器中“删除”了所有内容,则可以运行软件来还原数据,因为1和0仍然存在,您只需删除所有硬链接。恢复软件的目的是重建硬链接以理解0和1

我读了一个很棒的“一个班轮”,这一切都说得通,我想分享!

Linux中的所有文件都是磁盘上0和1的“硬链接”。当您创建数据(0和1)时,操作系统会在文件树中创建一个硬链接以引用硬盘上的该点。

创建HARD LINK 2并删除HARD LINK 1 原始文件

您可以创建另一个硬链接并删除原始文件,并且仍然可以访问新创建的硬链接。

删除被软链接到的文件(HARD LINK 1):

如果删除了HARD LINK 1,您是否认为SOFT LINK可以工作?否,操作系统将报告不存在HARD LINK 1。

删除SOFT LINK到HARD LINK:

相反,如果删除SOFT LINK,则HARD LINK会起作用吗?是。只要操作系统具有一个HARD LINK 文件,它将报告该填充未被删除。

-还值得研究/注意的是BIND,它是BIND两个目录的一种方式,例如符号链接两个目录,但是对操作系统是透明的(操作系统可以告诉您Symlink,并且某些人有天气规则可以遵循Symlinks)。它使用Mount(而不是LS),并且可以通过FSTAB进行配置。

什么是BIND支架


1
这是一个很大的努力,尤其是对于第一篇文章。不幸的是,我认为在“ bind”上添加材料(并没有要求)只会使事情变得混乱。尤其是因为您似乎并没有花太多精力来解释 “绑定”安装。另外,我非常了解硬链接和软链接/符号链接,并且我几乎不了解您的图片。如果初学者可以从中学到任何东西,我会感到非常惊讶。
G-Man

虽然可以符号链接目录,但它在文件系统中显示为符号链接,如果您使用BIND,则对操作系统是透明的。像文件一样显示。
FreeSoftwareServers 2015年

1
(1)实际上,在至少某些版本的Linux上,您可以绑定安装文件。(2)尽管绑定安装看起来与硬链接非常相​​似,但是说“绑定与硬链接完全相同(除非您不能硬链接目录)”简直是错误的。
G-Man

@ G-Man,同意并删除,只有一条提及BIND的注释
FreeSoftwareServers 2015年

@Free实际上,软链接指向文件(硬链接1);原理图,应该使这一点显而易见。
JB。


0

这是一个非常老的问题,但是我有一个用例,要求我使用硬链接。

我是一名音乐家,所以我的Mac附带的几个硬盘驱动器上有很多各种各样的音频文件。兆兆字节。我使用symlink目录对它们进行了很好的组织,以便可以根据内容发布者,样式/声音以及其他基于我当时的想法的条件来找到它们。不幸的是,我使用的一个程序Ableton Live完全无法从其文件浏览器中查看别名或符号链接。我发现的唯一解决方案是创建我希望它能够看到的目录的硬链接,然后一切正常。

因此,这是另一种情况,您可能需要使用硬链接,而其他人可能没有。


我会提交Ableton Live的错误报告。也许他们能够解决此问题。
aventurin

是的,多年来在abletons论坛上已经有很多关于此问题的抱怨……尽管我不知道为什么,但他们似乎并没有做出任何解决的尝试。
乔纳森·范·克卢特
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.