问题描述
正如标题所示，我想知道命令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和所有…
请享用！