Linux – 文件系统 – 理解目录 – 理解软/硬链接

首页
linux
正文

本文介绍: 在上篇博客当中，我们对文件系统和 inode 做了初步了解，本博客将在上篇博客的基础之上，对于文件系统当中的目录进行进步一阐述。

前言

在上篇博客当中，我们对文件系统和 inode 做了初步了解，本博客将在上篇博客的基础之上，对于文件系统当中的目录进行进步一阐述。

目录的数据块当中，存储的是目录当中的文件的 文件名 和 各个文件对应的 inode 的映射关系。

所以，一个文件的文件名不是存储在这个文件的属性（inode）当中的，文件的文件名不是这个文件的属性，这个文件的文件名和这个文件对应的 inode 的映射关系是存储在当前文件所以在目录的内容当中的。

所以，比如 ls 这个命令，在查找当前目录下的文件和目录的话，其实就是在当前目录的内容当中找到本目录下的文件名和各个文件映射的 inode 关系，根据命令行参数选项，打印出这个文件对应的信息即可。

所以，如果我们想要进入某一个目录当中，那么这个目录就要有 x 权限；当我们在某一个目录当中创建一个新的文件，或者是要删除某一个文件，需要这个目录有 w 权限。

因为，就算我们在一个没有 w 权限的目录执行路径当中创建一个了一个新的文件，但是，这个文件的文件名和这个文件对应的 inode 映射关系是不能再保存在这个目录文件对应的数据块当中。

同样，如果是这个目录是没有 r （读）权限的，那么这个目录当中的文件是不能访问的，因为要像访问一个文件，或者是修改一个文件，那么就要拿到这个文件的 inode 。但是，因为目录文件是不给读的，所以拿不到想访问文件的inode，那拿不到 inode 怎么访问文件呢？

而像是绝对路径和相对路径，也是同一个根目录或者是当前目录文件的数据块当中，一层一层递归的方式来寻找的。

所以，如果我们要想访问当前目录当中的某一个目录的话，就需要找到这个目录的 inode，才能访问到这个目录文件。

但是，要先找到这个目录的 inode ，就要在这个目录的上一层的目录文件的数据块当中找到这个目录文件的 inode映射关系。

到这你可能就会想，那么这不就递归了吗？我们要想找到这个目录的 inode 就要一直往上去递归式的去寻找。

是的，是递归式的寻找，但是，不是无穷无尽的递归，因为我们从任何路径当中往上来递归式寻找的话，一定可以找到一个目录 — 根目录。

所以，绝对路径就是先递归式的返回遍历到根目录，再根据给出的绝对路径来找到对应文件。

相对路径就更简单了，只要是当前目录路径已经被找到了，只需要按照相对路径当中给出的路径来进行查找即可。

得出结论：

在Linux 当中，访问任何一个路径都需要带上路径，可能你在使用 ls 等等这些命令的时候，没有带上路径，但是同样也访问到了目录文件，或者是文件当中的内容。其实这些命令访问文件也是要路径的，只不过，我们可以通过设置一些环境变量来提前保存一些路径，这些我们称之为 — 默认路径，系统就会默认从这个路径当中来访问文件，但是其实本质上也是通过路径来访问到内容的。

而，像上述要像递归到根目录的方式，来查找文件，这种方式太慢了，所以，在 Linux 当中，会把我们曾经访问过的，或者是经常访问的若干目录，已经这些目录当中的若干信息（比如文件映射的 inode，文件名等等信息），缓存一份。—- dentry缓存。

当我们需要访问缓存当中存在的文件之时，就可以直接从缓存当中读取到这个文件的 inode 等等信息，直接访问到这个文件了，不需要再去递归式的寻找文件位置。

软链接和硬链接

我们先来看是如何创建一个文件的 软链接 和 硬链接的：

软链接;

上述就是创建一个软链接，此时就有一个 text_link 指向 text.c 文件了。

如果你查看这个 text_link 的属性，你会查看到这个 text_link 有 inode ，说明这个 text_link是一个文件，而且，在这个文件的后面还有一个数字，你可以看到是1：

你可以发现这个 text_link是有 inode的，说明这个 text_link是一个文件，而且，在这个 text_link 和 text.c 两个文件的访问权限后面还有一个数字1 ，这个数字1 我们在后面说到硬链接的时候再叙述。

所以，此时也就是相当于是有一个 text_link 软链接文件指向了 text.c 这个文件。

硬链接：

像上述就生成一个硬链接文件。

同时，这个新生成的 text_link 硬链接文件，也是有 inode 的，但是这个 inode 是和 text.c 文件是一样的，说明这个硬链接不是一个独立的文件，而且，此时，在 text_link 这个文件的访问权限符后面的数字，变成了2。

而且，相信你还注意到，我们对应生成目标文件的硬链接文件的目标文件，也就是 text.c 这个文件。在文件访问权限符之后的数字，在生成硬链接文件之前，本来是 1 的，但是在生成硬链接文件之后就变成了2。

对于上述的结果，我们先不做阐述，我们下来看看生成软链接文件和硬链接文件之间的语法是什么：

其实，都是使用 ln 这个语法，但是吗，如果是软链接文件，需要带上 -s 这个选项参数，其实这里的 -s 就是 Soft 软的这个单词的缩写。

如不带上 -s 这个选项那么，默认就是硬链接文件的生成方式。、

创建软链接和硬链接的语法：

ln -s 被指向文件名 生成的目标指向文件的软链接文件名
ln 被指向文件名 生成的目标指向文件的软链接文件名



ln -s text.c text_link   #生成一个text_link 软链接文件指向 text.c 文件
ln  text.c textlink   #生成一个text-link 硬链接文件指向 text.c 文件

我们先来说说，上述所说的在文件访问权限符之后的数字代表的是什么意义？

其实这个数代表的意义是代表这个文件当前的硬链接个数。（其实就是当前 inode 的使用文件的引用计数）

其实，此时，如果我们把同一个文件的 软链接文件 和硬链接文件 ，都创建出来：

你会发现，硬链接文件（上图的text-link文件）和链接的文件（上图的text.c文件）的 inode 是一样的。

但是，软连接文件的 inode 和其他两个文件的 inode 是不一样的。

硬链接不是一样的独立的文件，因为硬链接文件没有独立的 inode。

理解硬链接

因为硬链接文件的 inode 和链接的文件的inode是一样的。所以，这两个文件的属性应该是一样的。

这里也侧面的证明了，文件的文件名是不在文件的inode 当中存储的，而是在目录当中存储的。

而，所谓的建立硬链接，本质上其实就是在特定的目录的数据块当中，新增文件名和文件和inode 的映射关系。

简答来说，就是在目标文件所在目录的内容当中（也就是在目录的数据块当中），把新按照目标文件生成的硬链接文件的文件名和对应的 inode 映射关系，保存到目标文件所在目录的内容当中。

如果此时，我们在 硬链接文件存在的情况下，删除这个硬链接文件链接的目标文件的话，会出现什么结果呢？

上述是结果，下述是删除 text.c 文件之前的结果：

发现，就算我们删除了text.c 这个文件，但是，硬链接文件并没有失效，inode 还是和之前一样，跟删除的目标文件的 inode 保持一致，并没有发生改变。

但是，引用计数变成了1，因为此时硬链接个数又变成了1个。

像上述这种，先创建一个文件的硬链接文件，然后删除掉这个文件，保存这个文件的硬链接文件，这个操作被称之为 — 取别名。

所以，在每一个 inode 内部，都有一个作用于当前 inode 硬链接个数的 引用计数。

而，在目录当中，保存了每一个文件名对应映射的 inode 的信息。

可以存在不同的文件名，映射到同一个 inode 当中。

所以，现在我们可以有一个更好的对于 引用计数的概念，不在是硬链接文件个数了，而是 有多少个文件名映射该 inode。

理解软链接

软链接文件当中，你可以发现，其实软链接文件是一个新创建的独立的文件。因为在创建之后，有独立的 inode。所以，软链接不会影响链接的目标文件的引用计数。

那么既然有独立的 inode ，也就意味着有独立的数据块，也就是说有独立的存储空间，在这个文件当中要存储什么呢？

存储的是指向的目标文件的路径。

其实你可以理解为在软链接当中存储的是，指向目标文件的指针，通过这个指针可以访问到这个软链接指向的目标文件。

发现，在text.c 当中重定向的字符串 a a a a a ，通过 text-link 这个软链接文件也可以访问到。

所以，既然存储的是指针，那么就会有 野指针的情况，当我们把软链接指向的目标文件删除之时，那么这个软链接文件当中存储的指针就会失效、

如上所说，从蓝色的软连接文件名，变成了红色的，此时代表的意思就是已经出现连接错误了。

其实，这个软链接特别像 windows 当中 程序的快捷方式。

当我们查看这些程序的快捷方式的属性的话，可以看见一个目标的属性：

其实这个就是我们上述所说的，软链接当中存储的是指向目标文件的路径。其实是一样的。

为什么要有软硬链接

我们日常使用的程序软件，其实都不简简单单是一个 xx.exe 这种直接点击就能运行的程序。整个程序一般还是有自己的配置文件，或者是程序运行所需要的文件数据信息，所以，往往一个程序的 xx.exe 是藏在一个较深的路径当中：

而，如果我们想在当前目录下（不在这个程序的 xx.exe 文件下）直接运行这个程序的话，就必须要带上绝对路径或者是相对路径。

但是类似 D:/Prog ramFiles(x86)/Huorong/Sysdia g/bin/xxx.exe 这行来运行这个可执行程序就太麻烦了，所以，可以使用软连接的方式创建快捷方式，来调用这个可执行程序：

同样，按照上述的方式，我们可以在Linux PATH 环境变量当中创建出我们自己，或者是第三方的程序的软链接文件，这样就可以直接输入文件名，不用的现去在当前目录下创建对应的软链接文件，都可以直接调用我们想安装的程序的可执行文件了：

此时我们就可以直接，在任何路径下调用这个我们刚刚安装的程序了：

所以，这个软件安装到哪里都可以，只要在 PATH 环境变量指向的系统默认的路径目录当中创建了这个程序的软链接程序，就可以随时随地调用这个程序了。

其次，当你创建了一个新的目录，那么你会发现，这个目录的 硬链接个数是 2 个。其实你应该已经猜到为什么了：

在上图当中，就有一组 inode 和文件名的关系，就是当前的dir 这个目录文件名和这个文件的inode 的映射关系。现在我们进入到这个目录当中，查看这个目录当中所有文件，包括隐藏文件：

有一个 “.” 作为文件名的文件，很多读者应该知道，这个 “.” 文件，代表的是当前所在所在目录的这个目录的文件。

也就是说，在 dir 这个目录当中的 “.” 这个文件，和 dir 这个目录文件所映射的 inode 是一样的，两个映射的是同一个 inode，代表的是同一个文件。

而且如上图所示，你可以发现 dir 和 dir当中的 “.” 这两个文件名的 inode 是相同的。

所以，这里你就可以理解了，为了每一个目录当中的 “.” 文件，都可以代表的是当前目录文件。

上述也提到了 “..” 两个点的文件名，这个文件代表的是当前目录的上级目录文件，和上级目录文件共用的是同一个inode。

所以，按照这个推理的话，在上述创建 dir 这个目录所在目录，应该就有 3 个硬链接个数了，因为在 dir 当中还有一个 “..” 文件是映射的这个目录：

如上图所示，ln_text 目录就是 dir 所在的目录，是三个硬链接个数。

同样你可以查看 “/” 根目录 的硬链接个数：

发现是一个很大数字，因为在 “/” 目录当中已经创建了很多个目录了，每一个目录当中都有一个 “..” 硬链接上 “/” ，所以才会有这么多。

所以，往后，如果想知道某一个目录当中有多少个有效目录（也就是想上述 dir 这样目录）其实可以像上诉一样查看这个目录的硬链接个数，该目录的 硬链接个数 – 2 就是这个目录当中的有效目录。

Linux 当中的目录结构是一个多叉树，Linux 当中的文件系统是利用上述的硬链接方式，来维持多叉树当中每一个结点当中的有 parent指针和指向当中结点的指针，这样一个关系。我们称之为 — 路径定位。实现目录间的切换。

然后使用在目录当中存储的文件名和文件名所映射的 inode 来位置当前结点的孩子结点直接的关系。

在上述你可能有疑问，为什么可以直接用一个目录的硬链接个数来确定其中的有效目录个数？

就不怕用户自己使用 ln 这个指令来对这个目录文件进行硬链接吗？

其实不怕。因为 目录是不能使用 ln 创建硬链接的。

如上所示，我们发现报错了，报错信息是链接不允许是目录。

但是，目录是可以建立软链接的。

这里需要注意是：如果你想删除某一个软链接的话，可以使用 rm 命令，但是有的时候是删不掉的，这个时候更多的使用的事 unlink 软链接文件名 这样的方式来进行删除软链接文件的。

为什么Linux 不给目录建立硬链接？

我们可以假设一下，然后来考虑为什么。其实很简单，就是一个循环引用计数的问题。

如上图所示，dir 目录文件是 ln_text 目录文件的硬链接，dir 就相当于是我们在某一个目录下创建的一个ln_text 目录文件的硬链接文件。

那么在上述多叉树文件系统当中，如果我想从 ln_text 找到 dir 这个目录的话，从上图当中的红色路径就可以找到，但是，当我们找到 dir 之后，它的 inode 又是 2（和 ln_text 是一样的），所以此时就会回去找到 ln_text 目录，又回到最初的起点，但是还是没有找到，所以又会像之前一样往下递归找到 dir 目录·······

这不就是一个循环了吗？

而，上述说过 “.” 和 “..” 两个文件不也是建立了硬链接吗？

这两个文件不是用户建立的，是操作系统自己建立的，它在建立之初，因为这两个文件和自己硬链接的文件不会像上个例子一样隔个十万八千里，人家就是表示的当前目录和上级目录，所以这个在操作系统内部可以实现。但是如果放在很长的文件系统多叉树结构当中就不好实现了。

换句话说，操作系统自己能够实现目录的硬链接，本质上其实是操作系统只相信自己，不相信任何人，包括 root 。

同样你也可以发现，关于 “.” 和 “..” 这两个文件是不能做搜索操作的吗，只能在路径定位当中使用。