问题描述
正如标题所示,我想知道命令ln
创建的硬链接和软链接之间的区别。命令man ln
确实提供信息,但没有充分回答我的问题。
另外,如果有人能提供一个硬链接比符号链接更可取的设置,那将会很好。
最佳解决方案
“一张图片胜过千言万语。”
而且,“一个例子值得一百段……”
创建两个文件:
$ touch blah1
$ touch blah2
在其中输入一些数据:
$ echo "Cat" > blah1
$ echo "Dog" > blah2
和预期的一样:
$cat blah1; cat blah2
Cat
Dog
让我们创建硬链接和软链接:
$ ln blah1 blah1-hard
$ ln -s blah2 blah2-soft
让我们看看刚刚发生的事情:
$ ls -l
blah1
blah1-hard
blah2
blah2-soft -> blah2
更改blah1的名称并不重要:
$ mv blah1 blah1-new
$ cat blah1-hard
Cat
blah1-hard指向文件的inode,内容 – 没有改变。
$ mv blah2 blah2-new
$ ls blah2-soft
blah2-soft
$ cat blah2-soft
cat: blah2-soft: No such file or directory
该文件的内容找不到,因为软链接指向的名称已更改,而不是内容。同样,如果blah1被删除,blah1-hard仍然保存内容;如果blah2被删除,blah2-soft只是一个到non-existing文件的链接。
来源:公然从StackOverflow!复制它
次佳解决方案
硬链接不是指向文件的指针,而是指向相同索引节点的目录条目(文件)。即使您更改了其他文件的名称,硬链接仍指向该文件。如果使用新版本替换其他文件(通过复制),硬链接将不会指向新文件。您只能在同一个文件系统中拥有硬链接。对于硬链接,您不具有原始文件和链接的概念,都是平等的(将其视为对象的引用)。这是一个非常低的概念。
另一方面,符号链接实际上指向另一个路径(文件名);它会在每次通过符号链接访问文件时解析文件的名称。如果你移动文件,符号链接将不会跟随。如果将文件替换为另一个文件,保留名称,符号链接将指向新文件。符号链接可以跨越文件系统。使用符号链接,您可以非常清楚地区分实际文件和符号链接,它不在关于它指向的文件的路径旁边存储任何信息。
第三种解决方案
两者都是指向文件的指针;区别在于指针的种类。符号链接按名称指向另一个文件。它有一个特殊的模式位,将其标识为符号链接,其内容是实际文件的名称。由于它只包含一个名称,该名称实际上并不存在,或者可能存在于不同的文件系统中。如果替换指定文件(更改其内容而不影响其名称),则链接仍包含相同的名称,因此现在它指向新文件。您可以轻松识别符号链接并查看它指向的文件的名称。
硬链接通过inode编号指向文件。因此,硬链接与文件的名字没有区别。没有”real”名称与硬链接名称;所有硬链接都是文件的有效名称。因此,链接的文件必须实际存在,并且位于您尝试创建链接的相同文件系统中。如果删除原始名称,则硬链接仍指向同一文件。由于所有硬链接对于文件而言都是同样有效的名称,因此您无法查看该文件并查看该文件的其他名称;要找到这个,你必须查看每个文件并比较它们的inode编号以找到具有相同inode编号的其他名称。
您可以从ls -l
的输出中知道文件的名称。文件模式之后的第一个数字是链接数。具有多于1个链接的文件在某处存在其他名称,相反,链接数仅为1的文件没有(其他)硬链接。
第四种方案
一个硬链接只能在相同的文件系统上工作,它对同一个inode来说只是一个不同的名称(文件被inode内部引用)。只有到其inode的最后一个链接消失时才会从磁盘中删除文件(您是rm
d或unlink
d最后一个链接)。硬链接通常只适用于文件,而不适用于目录。
符号链接(符号链接)是一个包含另一个文件路径的特殊文件。这条路可以是绝对的或相对的。符号链接可以跨文件系统工作,甚至可以指向不同的文件,例如,如果您拔出外部硬盘驱动器并将其替换为另一个文件系统,而该另一个文件具有相同路径上的不同文件。符号链接可以指向文件或目录。
第五种方案
其他线程(现在已经从帖子顶部链接)的答案之一提到了this page,我认为这是一个相当不错的medium-level解释。如果你迷失在ascii艺术中,这里是长话短说版本:
-
标准文件是从文件系统到inode的指针,inode又指向物理数据。文件组件存储其到文件系统(实质上是它的路径)的链接以及到inode的链接。
-
Hard-links,就像文件一样。它们只是一个直接指向inode的附加指针。
-
Symbolic-links是将文件系统路径存储到文件的独立文件(包括独立的inode和数据)。
涉及的内核和文件系统透明地翻译所有内容。
所以基于此:
-
Hard-links只允许same-filesystem链接。符号链接可以指向任何路径。
-
Hard-links(实质上)指向绝对数据。符号链接可以指向相对路径(例如
../parent.file
) -
通过扩展,如果移动hard-link的目标指针(记住,它本身本质上只是一个指向inode的hard-link),hard-link仍然有效。移动符号链接的目标通常会破坏符号链接。
-
解决hard-link会更快,但无法比拟。速度的微不足道的部分是以不灵活的文件系统为代价的。
我可能会对自己有点困惑,但是通过阅读各种各样的东西,我正在努力寻找标准文件和硬链接之间的区别。我读它的方式是每个文件由一个硬链接(存储文件名)组成,链接到指向物理数据的inode。
添加一个硬链接只是提供了一个inode和一个额外的filesystem-based指针。是对的吗?
第六种方案
在Linux /Unix中快捷方式被称为链接
链接有两种类型软链接(符号链接)或硬链接
-
软链接(符号链接)您可以创建文件和链接的链接。文件夹&您可以在不同的分区和分区上创建链接(快捷方式)。从原始获得不同的inode号码。如果真实副本被删除,该链接将不起作用。
-
硬链接仅适用于文件&你不能在不同的分区上创建(它应该在同一个分区上)&获得与原始相同的inode编号如果真实副本被删除,链接将起作用(因为它充当原始文件)
问题:如何制作软链接?
答案:一个软链接可以用ln -s
制作,第一,你需要定义源,然后你需要定义目的地(记住,你需要定义源和目的地的完整路径,否则它将不起作用)
sudo ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so.1 /usr/lib32/libGL.so.1
(----------Source-------) ( Destination )
正如你可以看到是否有不同的inode,并可以在不同的分区上创建
问题:如何制作硬链接?
答案:可以用ln
制作一个硬链接,第一,你需要定义源,然后你需要定义目的地(请记住,你需要定义源和目的地的完整路径,否则它将不起作用)
我在/脚本文件夹名称firefox中有一个脚本
ls -i ( Shows you the inode )
5898242 firefox
ln /scripts/firefox /scripts/on-fire
( Source ) ( Destination )
正如你可以看到它有相同的inode,并且如果我删除原始的链接,链接将起作用,因为它的行为与原创一样
第一我已检查链接是否正常工作,然后我删除了Firefox脚本
你问:如果有人能提供一个硬链接比符号链接更可取的设置,那将会很好。
答:根据磁盘分区布局,硬链接的限制必须在同一分区(-1点),并且可以是文件(-1点)),但+1点是如果删除原始链接,则链接将以其工作充当原创
其中软链接可以由文件夹&文件(+1点),没有分区限制(+1点),但只有(-1点)是,如果源被删除,链接将不起作用
第七种方案
何时使用软链接:
跨文件系统的链接:如果要跨文件系统链接文件,则只能使用符号链接/软链接。
指向目录的链接:如果要链接目录,则必须使用软链接,因为您无法创建到目录的硬链接。
何时使用硬链接:
存储空间:由于在创建硬链接时没有创建新的inode,因此硬链接的空间数量可以忽略不计。在软链接中,我们创建一个消耗空间的文件(通常为4KB,取决于文件系统)
性能:访问硬链接时性能稍好,因为您直接访问磁盘指针而不是通过其他文件。移动文件位置:如果您将源文件移动到同一文件系统的其他位置,硬链接仍然可以工作,但软链接将失败。
冗余:如果你想确保你的数据安全,你应该使用硬链接,就像在硬链接中一样,数据是安全的,直到文件的所有链接都被删除,而不是在软链接中,你将会失去数据如果文件的主实例被删除。
第八种方案
当您尝试查找“文件名”与硬链接之间的区别时会产生混淆,因为没有链接。
您创建的每个文件都由磁盘上的数据和硬链接组成 – 这是目录中的文件名和指向磁盘上数据的指针。故事结局。当最后(或唯一)的硬链接被删除时,操作系统知道数据不再需要。
从这里你可以看到实际的数据不会被删除,只有硬链接。当它充分拥挤在磁盘上时,数据可能会被另一个文件的数据覆盖。在此之前,删除文件中的数据可能会被恢复,但如果没有硬链接,很难找到。
如前所述,符号链接只是告诉你“在名为<targetfolder>
的文件夹中有一个名为<targetname>
的文件”。他们指向硬链接。他们不知道数据在哪里。硬链接知道这一点。
第九种方案
对于一个优秀的noob-and-ex-Windoze-user-friendly解释,与漂亮的图表和常见问题解答看看这个页面http://www.geekride.com/hard-link-vs-soft-link/。他们的copyright限制阻止我摘录他们的东西,所以我提供了链接。
这是我第二次甚至是第三次尝试抓住soft /hard-link的谜题,总是在不知不觉中将我的理解推迟到未来的某个不确定的时间点 – 只要解释和man-pages变得更加深入并且over-technical与inode和所有…
请享用!