linux系统 硬链接和软链接

背景：

当几个用户同在一个项目里工作时。经常须要共享文件。

假设一个共享文件同一时候出如今属于不同用户的不同文件夹下。工作起来就非常方便。

比如B和C文件夹下有一文件D是两者都能够訪问和改动的共享文件，这样是非常方便，但也会有一些问题，假设文件夹中包括磁盘地址，则当连接文件时。必须把C文件夹中的磁盘地址拷贝到B文件夹中，假设B或C随后又往该文件里加入内容，则新的数据块将仅仅列入进行加入工作的用户的文件夹中。

其它的用户对此改变是不知道的。违背了共享的目的。

两种方法解决这样的问题。

方法一：硬链接（实体连接或实际连接）

透过文件系统的inode 连结来产生新档名。而不是产生新档案！这样的又称 为实体链接 (hardlink).

· 每一个档案都会占用一个inode ，档案内容由 inode的记录来指向；

· 想要读取该档案。必项要经过文件夹记录的文件名称来指向到正确的inode 号码才干读取。    也就是说，事实上文件名称仅仅与文件夹有关，可是档案内容则与 inode 有关。那举想一想， 有没有可能有多个档名相应到同一个 inode 号码呢？有的！那就是 hard link 的由来。

所以简单的说：hard link 仅仅是在某个文件夹下新增一笔档名链接到某 inode 号码的关连记彔而已。

[

举个样例来说。如果我系统有个 /root/crontab 他是 /etc/crontab 的实体链接，也就是说这两个档名 连结到同一个 inode ，自然这两个文件名称的全部相关信息都会一模一样(除了文件名称之外)。实际的情况能够例如以下所看到的：

你能够发现两个档名都连结到 1912701 这个 inode 号码。所以您瞧瞧。是否档案的权限/属性全然一 样呢？ 由于这两个『档名』事实上是一模一样的『档案』啦！并且你也会发现第二个字段由原本的 1 发 成 2 了。 那个字段称为『连结』。这个字段的意义为：『 有多少个档名链接到这个 inode 号码』的意思。

假设将读取到正确数据的方式画成示意图。就类似例如以下画面：

你能够透过 1 或 2 的文件夹的 inode 指定的block 找到两个不同的档名，而无论使用哪 个档名均能够指到 real 那个 inode 去读取到终于数据！那这样有优点呢？最大的优点就是『安 全』！

如同上图中， 假设你将不论什么一个『档名』删除，事实上 inode 与 block 都还是存在的！

此时你能够透过还有一个『档名』来读取到正确的档案数据喔！此外，不论你使用哪个『档名』来编辑，终于的结果都会写入到同样的 inode 与block 中。因此均能进行数据的改动。攻克了上述的问题，一般来说，使用
hard link 设定链接文件时，磁盘的空间与 inode 的数目都不会改发。我们还是由图 2.2.1 来看，由图中能够知道。 hard link 仅仅是在某个文件夹下的 block 多写入一个关连数据而已。既不会添加 inode 也不会耗用 block 数量。

Tips:

简单来讲：硬链接就是同一文件使用了多个别名（有共同的inode），是不同的文件指向同样的inode。达到文件共享的目的；

长处：安全，改动同步。删除一个硬链接文件并不影响其它有同样inode号的文件；

缺点：不能跨 Filesystem，不能 link 文件夹。

不能跨Filesystem：由图 2.2.1 其实我们也可以知道，其实 hard link 应该仅能在单一文件系统中进行的。应该是不可以跨文件系统才对！

由于图 2.2.1 就是在同一个 filesystem 上嘛！所以 hard link 是有限制的。

不能link文件夹：由于假设使用 hard link 链接到目彔时， 链接癿数据须要连同被链接目彔底下的全部数据都建立链接，举例来说，假设你要将 /etc 使用实体链接建立一个 /etc_hd 的目彔时。那举在 /etc_hd 底下的全部档名同一时候都与/etc 底下的檔名要建立 hard link 的。而不是仅连结到 /etc_hd 与/etc 而已。

而且，未来假设须要在 /etc_hd 底下简历新档案时，连带的/etc底下的数据又得要建立一次hard link，因此造成环境相当大的复杂度。所以不能link文件夹。

hard link 的制作中，事实上还是可能会改发系统的block。那就是当你新增这笔数

据却刚好将文件夹的block 填满时。就可能会新加一个block 来记录文件名称关连性。

而寻致磁盘空间的变化。只是。一般 hard link 所用掉的关连数据量非常小。所以通常

不会改发 inode 与磁盘空间的大小喔

方法二：软链接（符号连接即快捷方式）

相对于hard link ， Symbolic link 可就好理解多了，基本上， Symbolic link 就是在建立一个独立的档案，而这个档案会让数据 的读取指向他link的那个档案的档名。由与仅仅是利用档案来做为指向的动作， 所以。当来源档被删除之后。symboliclink 的档案会『开不了』 ， 会一直说『无法开启某档案！』。实际上就是找不到原始『档名』而已啦！

举例来说，我们先建立一个符号链接文件链接到 /etc/crontab 去看看：

watermark/2/text/aHR0cDovL2Jsb2cuY3Nkbi5uZXQv/font/5a6L5L2T/fontsize/400/fill/I0JBQkFCMA==/dissolve/70/gravity/Center" alt="">

我们能够知道两个档案指向不同的iode 号码，当然就是两个独立的档案存在！ 并且连结档的重要内容就是他会写上目标档案的『文件名称』 ， 你能够发现为什么上表中连结档的大小为 12 bytes 呢？ 由于箭头(-->)右边的档名『 /etc/crontab』总共同拥有 12 个英文。每一个英文占用 1 个 byes ， 所以档案大小就是12bytes 了。 关于上述的说明，我们以例如以下图示来解释：

由 1 号 inode 读取到连结档的内容仅有档名，依据档名链接到正确的目彔去取得目标档案的inode ， 终于就能够读取到正确的数据了。你能够发现的是。假设目标档案(/etc/crontab)被删除了，那整个环节就会无法继续进行下去。所以就会产生无法透过连结档读取的问题了！ 这里还是得特别留意，这个 Symbolic Link 与 Windows 的快捷方式能够给他划上等号，由 Symbolic link 所建立的档案为一个独立的新的档案。所以会占用掉 inode 与 block 喔！ 由上面的说明来看。似乎
hard link 比較安全。由于即使某一个目彔下的关连数据被杀掉了， 也没有关系，仅仅要有不论什么一个目彔下存在着关连数据，那举该档案就不会不见！举上面的样例来说，我的 /etc/crontab 与 /root/crontab 指向同一个档案，假设我删除了 /etc/crontab 这个档案，该删除的动作事实上仅仅是将 /etc 目彔下关于crontab 的关连数据拿掉而已， crontab 所在的 inode 与 block 事实上都没有变动。

软链接：文件用户数据中有效的内容是还有一文件的路径名的指向。是一普通文件，数据块有点特殊。删除软链接不影响源文件。

长处：方便，能够用到文件夹。

仅仅要简单地提供一个机器的网络地址以及文件在该机器上驻留的路径。就能够连接全球不论什么地方机器上的文件。

缺点：须要额外的开销。必须读取包括路径的文件，然后要一个部分一个部分的扫描路径，直到找到inode节点，也须要额外的磁盘存取。删除源文件，链接文件为死文件。

由于硬链接应用受到限制。软链接应用较为广泛。