Linux下的链接文件详解
几个基本概念
Linux下的链接文件可以分为硬链接（hard link）与软链接（soft link）。要理解它们，必须先要理解几个基本概念。
inode
文件除了纯数据本身之外，还必须包含有对这些纯数据的管理信息，如文件名、访问权限、文件的属主以及该文件的数据所对应的磁盘块等等，这些管理信息称之为元数据（mata data），保存在文件的inode节点之中。我们可以通过stat命令查看一个文件的inode信息：
$ stat /etc/passwd File: "/etc/passwd" Size: 936 Blocks: 8 IO Block: 4096 普通文件 Device: fd00h/64768d Inode: 137143 Links: 1 Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root) Access: 2016-08-05 23:01:39.905999995 +0800 Modify: 2016-07-15 16:36:12.802999997 +0800 Change: 2016-07-15 16:36:12.809000014 +0800 $ ls -l /etc/passwd -rw-r--r-- 1 root root 936 7月 15 16:36 /etc/passwd
这里我们查看了/etc/passwd文件的元数据信息。ls -l命令也会列出一些文件的元数据信息（由左至右分别为：权限、硬链接数、属主、属组、文件大小、最近更改时间、文件名），但相比之下，stat命令输出的信息更加完整。我们注意到，stat输出的信息中，文件有三个时间戳：最近访问、最近更改和最近改动，对应于英文分别为Access、Modify和Change。 Access time比较好理解，当每次访问这个文件的数据（注意，不是元数据），这个时间就会更新。比如用cat或者more命令读取文件内容时，会更新access time，而用ls或者stat命令，由于只是访问了文件的inode，所以不会更新access time值。Modify time是文件数据最后一次被修改时间，比如用vim编辑文件后保存文件，此时就会更新该文件modify time。Change time是文件元数据（即inode）最后一次被修改的时间，比如用chown命令修改文件的属主，此时就会更新文件的change time。
其实最初当我们创建分区并用mkfs.ext4等命令创建文系统的时候，就已经在文件系统的固定区域保留了inode节点区。我们可以通过df -i命令查看某文件系统inode节点区域的大小及使用情况：
# df -ih /dev/mapper/pdc_bcfaffjfaj2 文件系统 Inode 已用(I) 可用(I) 已用(I)% 挂载点 /dev/mapper/pdc_bcfaffjfaj2 18M 127K 18M 1% /home
可以看到，在笔者的Linux Mint17.3系统中，分区/dev/mapper/pdc_bcfaffjfaj2共保留了18M的inode区域，这个区域目前已经使用了127K。有没有可能出现某分区尚有空间而inode区域已用完的情况呢？有的。当小文件特别多的时候就会出现这种情况！这个时候即使文件系统还有空间可用，但我们仍然无法继续在这个文件系统内创建新的文件了。那假如在我的应用环境中真的小文件非常多该怎么办？其实我们在建立ext4文件系统时候是可以手动指定inode区域所占的比例大小的，可以man mkfs.ext4查看相关的参数和选项，这里不再详述。
刚才用stat查看文件的inode信息时，我们看到输出的信息中有一行Inode: 137143，这个是/etc/passwd文件的inode号。每个inode都有一个全文件系统唯一的inode号，操作系统内核正是通过inode号而非文件名来识别不同的文件。文件名仅仅是为了方便用户使用而已，内核是通过文件名找到inode，然后通过inode访问实际文件数据的。有没有可能有多个文件名对应于同一个inode呢？有的，这样就产生了所谓硬链接文件。
dentry
虽然每个文件对应了唯一的inode号，但inode号是杂乱而毫无意义的，不方面用户记忆和使用，我们希望对每个文件取一个有意义的文件名。现代文件系统提供的一个基本功能是按名存取，所以我们还需要建立文件名到inode号的对应，这就引出了目录项（directory entry即dentry）的概念。在Linux文件系统中有一类特殊的文件称为“目录”，目录就保存了该目录下所有文件的文件名到inode号的对应关系，这里的每个对应关系就称为一个dentry。而Linux把所有的文件和目录构建成了一个倒立的树状结构，这样，我们只要确定了根目录的inode号，就可以对整个文件系统进行按名存取了。
hard link
硬链接的实质是现有文件在目录树中的另一个入口。也就是说，硬链接与原文件是分居于不同或相同目录下的的dentry而已，它们指向同一个inode，对应于相同的磁盘数据块（data block），具有相同的访问权限、属性等。简而言之，硬链接其实就是给现有的文件起了一个别名。如果把文件系统比喻成一本书的话，硬链接就是在书本的目录中，有两个目录项指向了同一页码的同一章节。
硬链接的优点是几乎不占磁盘空间（因为仅仅是增加了一个目录项而已），但是这一优点相对于软链接其实并不明显（因为软链接占用的磁盘空间也很少）。另外，硬链接有以下一些局限：1、不能跨文件系统创建硬链接。原因很简单，inode号只有在一个文件系统内才能保证是唯一的，如果跨越文件系统则inode号就可能重复。2、不能对目录创建硬链接。原因我在稍后解释。正因为硬链接的这些局限，加之软链接更加易于管理，所以软链接更加常用。这一点在本文中举的例子也可以看出，几乎都是软链接的例子。
soft link
软链接又称为符号链接（symbolic link），简写为“symlink”。与硬链接仅仅是一个目录项不同，软连接本身也是文件，不过这个文件的内容是另一个文件名的指针。当Linux访问软链接时，它会循着指针找出含有实际数据的目标文件。我们还以书本来打比方，软链接是书本里的某一章节，不过这一章节什么内容都没有，只有一行字“转某某章某某页”。
软链接可以跨越文件系统指向另一个分区的文件，甚至可以跨越主机指向远程主机的一个文件，也可以指向目录。在ls -l输出的文件列表中，第一个字段有“l”字样者表示该文件是符号链接。
$ ls -l total 0 lrwxrwxrwx 1 wjm wjm 11 Aug 10 00:51 hh -> /etc/passwd
我们看到，软链接的权限为777，即所有权限都是开放的，实际上你也无法使用chmod命令修改其权限，但是实际文件的保护权限仍然起作用。
另外，符号链接可以指向不存在的文件（可能是原来指向的文件被删除了，或者指向的文件系统尚未挂载，或者最初建立该符号链接的时候就指向了一个不存在的文件等等），我们称这种状态为“断裂”（broken）。与之相对的是，硬链接是不能指向一个不存在的文件的。
使用链接有何好处？
我们在此总结使用链接文件的以下几个的好处：
保持软件的兼容性
例如，在RHEL6中我们看下面这条命令的输出：
$ ls -l /bin/sh lrwxrwxrwx. 1 root root 4 Jul 15 11:41 /bin/sh -> bash
我们看到，/bin/sh文件其实是一个指向/bin/bash的符号链接。为什么要这样设计？因为几乎所有的shell script的第一行都是下面这样：
#!/bin/sh
“#！”符号表示该行指定该脚本所用的解释器。#！/bin/sh表示使用Bourne Shell作为解释器，这是一个早期的Shell。在现代的Linux发行版中通常采用Bourne Again Shell即bash，bash是对sh的改进和增强，而早期的Bourne Shell在系统的中根本不存在。为了能够顺利的运行脚本而不必修改shell script，我们只需要创建一个软链接/bin/sh让其指向/bin/bash。如此一来，就可以让bash来解释原本针对Bourne Shell编写的脚本了。
方便软件的使用
比如我们安装了一个大型软件Matlab，它可能默认安装在/usr/opt/Matlab目录下，它的可执行文件位置在/usr/opt/Matlab/bin目录下，除非你在这个路径加入到PATH环境变量里，否则每次运行这个软件你都需要输入一长串的路径很不方便。你还可以这样做：
$ ln -s /usr/opt/Matlab/bin/matlab ~/bin/matlab
通过在你的~/bin下创建一个符号链接（~/bin系统默认已经包含在PATH环境变量里的），今后在命令行下无需输入完整路径，只需输入matlab即可。
维持旧的操作习惯
比如在SuSE中，启动脚本的位置是放在/etc/init.d目录下，而在RedHat的发行版中，是放在/etc/init.d/rc.d目录下。为了避免因为从SuSE转换到RedHat系统而导致管理员找不到位置的情况，我们可以创建一个符号链接/etc/init.d使其指向/etc/init.d/rc.d即可。事实上，RedHat发行版也正是这样做的：
$ ls -ld /etc/init.d/ lrwxrwxrwx. 1 root root 11 Jul 15 11:41 init.d -> rc.d/init.d
方便系统管理
最让人印象深刻的一个例子应该是/etc/rc.d/rcX.d目录下的符号链接了（X为0~7数字）。
$ ls -l /etc/rc.d/ total 60 drwxr-xr-x. 2 root root 4096 Jul 15 16:36 init.d -rwxr-xr-x. 1 root root 2617 Nov 23 2013 rc drwxr-xr-x. 2 root root 4096 Jul 15 16:36 rc0.d drwxr-xr-x. 2 root root 4096 Jul 15 16:36 rc1.d drwxr-xr-x. 2 root root 4096 Jul 15 16:36 rc2.d drwxr-xr-x. 2 root root 4096 Jul 15 16:36 rc3.d drwxr-xr-x. 2 root root 4096 Jul 15 16:36 rc4.d drwxr-xr-x. 2 root root 4096 Jul 15 16:36 rc5.d drwxr-xr-x. 2 root root 4096 Jul 15 16:36 rc6.d -rwxr-xr-x. 1 root root 220 Nov 23 2013 rc.local -rwxr-xr-x. 1 root root 19688 Nov 23 2013 rc.sysinit
在init.d/目录下有许多用于启动、停止系统服务的脚本，如sshd、crond等。这些脚本可以接受一个参数，代表要启动（start）或停止（stop）服务。为了决定在某个运行级别运行哪些脚本及传递给这些脚本哪些参数，RedHat设计了一个额外的目录机制，即rc0.d到rc6.d的7个目录，每个目录对应一个运行级别。如果在某运行级别下需要启动某服务或者需要停止某服务，就在对应的rcX.d目录下建立一个符号链接，指向init.d/目录下的脚本。如：
$ ls -l /etc/rc.d/rc3.d total 0 lrwxrwxrwx. 1 root root 19 Jul 15 11:42 K10saslauthd -> ../init.d/saslauthd lrwxrwxrwx. 1 root root 20 Jul 15 11:42 K50netconsole -> ../init.d/netconsole lrwxrwxrwx. 1 root root 21 Jul 15 11:42 K87restorecond -> ../init.d/restorecond lrwxrwxrwx. 1 root root 15 Jul 15 11:42 K89rdisc -> ../init.d/rdisc lrwxrwxrwx. 1 root root 22 Jul 15 11:44 S02lvm2-monitor -> ../init.d/lvm2-monitor lrwxrwxrwx. 1 root root 19 Jul 15 11:42 S08ip6tables -> ../init.d/ip6tables lrwxrwxrwx. 1 root root 18 Jul 15 11:42 S08iptables -> ../init.d/iptables lrwxrwxrwx. 1 root root 17 Jul 15 11:42 S10network -> ../init.d/network lrwxrwxrwx. 1 root root 16 Jul 15 11:44 S11auditd -> ../init.d/auditd lrwxrwxrwx. 1 root root 17 Jul 15 11:42 S12rsyslog -> ../init.d/rsyslog ... ....
这里列出了在运行级3下需要运行的服务脚本及对应的参数，其中符号链接的第一个字母S和K分别表示传递参数start和stop，后面跟着的两位数字表示脚本运行的先后顺序。这样一来，只要在rcX.d目录下新增或者移除链接，就可以控制各个runlevel需要运行哪些服务脚本；而如果需要修改某个服务脚本，只需要编辑init.d/目录下的文件（“本尊”），而它可以影响所有rcX.d目录下的软链接（“分身”）。这是多么简洁而巧妙的设计!
ln命令
我们用ln命令创建硬链接或者软链接。其语法为：
ln [options] file link
此命令的第一种形式会创建一个指向file的新的链接，其中options选项，我们只记住一个就行，-s表示创建软链接，而默认会创建硬链接。例如：
# ln -s /usr/src/linux-2.6.32 /usr/src/linux
这里，我们创建了一个符号链接/usr/src/linux，指向真实的Linux源代码目录/usr/src/linux-2.6.32。
我们再举一个例子，演示一下软链接与硬链接的区别，我们创建一个myfile文件，然后再创建一个指向该文件的软链接myslink和硬链接myhlink：
$ $ echo "an example." > myfile $ ln -s myfile myslink $ ls myfile myhlink
使用stat检查前述文件：
$ stat my* File: `myfile' Size: 12 Blocks: 8 IO Block: 4096 regular file Device: fd00h/64768d Inode: 11552 Links: 2 Access: (0664/-rw-rw-r--) Uid: ( 500/ wjm) Gid: ( 500/ wjm) Access: 2016-08-10 03:59:54.421017669 +0800 Modify: 2016-08-10 03:59:54.421017669 +0800 Change: 2016-08-10 04:00:08.689000105 +0800 File: `myhlink' Size: 12 Blocks: 8 IO Block: 4096 regular file Device: fd00h/64768d Inode: 11552 Links: 2 Access: (0664/-rw-rw-r--) Uid: ( 500/ wjm) Gid: ( 500/ wjm) Access: 2016-08-10 03:59:54.421017669 +0800 Modify: 2016-08-10 03:59:54.421017669 +0800 Change: 2016-08-10 04:00:08.689000105 +0800 File: `myslink' -> `myfile' Size: 6 Blocks: 0 IO Block: 4096 symbolic link Device: fd00h/64768d Inode: 11553 Links: 1 Access: (0777/lrwxrwxrwx) Uid: ( 500/ wjm) Gid: ( 500/ wjm) Access: 2016-08-10 04:00:03.784997923 +0800 Modify: 2016-08-10 04:00:03.784997923 +0800 Change: 2016-08-10 04:00:03.784997923 +0800
仔细观察myfile和myhlink，发现它们指向同一个inode（inode号同为11552）。硬链接数（Links字段）同为2，这表示有两个目录项指向该inode，每增加一个硬链接Links字段值就会增加1。而myslink文件，我们发现它的inode号与前两个不同，其访问权限为0777。我们删除myhlink这个硬链接，看看会出现什么变化？这次我们用ls -il命令来查看：
$ rm myfile $ ll -li total 4 11552 -rw-rw-r-- 1 wjm wjm 12 Aug 10 03:59 myhlink 11553 lrwxrwxrwx 1 wjm wjm 6 Aug 10 04:00 myslink -> myfile $ cat myhlink an example. $ cat myslink cat: myslink: No such file or directory
ls命令的-i选项也可以输出文件的inode号。输出信息的第三列为硬链接数，我们发现删除了myfile文件后，myhlink的硬链接数已经由2变为1了,但是原myfile文件的数据依然可以通过myhlink这个硬链接访问，因为硬链接是通过文件的inode号来访问文件数据的。然而通过myslink软链接却无法再访问原myfile文件的数据了，因为软链接实质上是一个指向目标文件的全路径，这个路径中任何一个环节断裂，都会使这个软链接失效。
追随链接
自从了软连接，当你要备份、复制或者移动目录或者文件时候，会出现是否要“追随链接”的问题。如果是，则会复制链接所指向的对象；如果不是，则仅仅操作链接本身。
通常如tar或cp之类的命令工具会给出是否追随链接的选项。如cp，你可以使用-L选项表示追随链接（复制链接所指向的目标），或者用-P表示不追随链接（复制链接本身）。如下例：
$ mkdir dir1 $ ln -s /tmp/a.txt dir1/slink $ cp -rL dir1 dir2 $ ls -l dir2 total 0 -rw-rw-r-- 1 wjm wjm 0 Aug 6 17:02 slink
这里我们在dir1目录下创建了一个软链接，当用-L选项将其复制到dir2目录下时，我们看到dir2目录下的slink现在成为一个普通文件。如果使用-P选项（保存链接）复制，则复制后的文件依然是一个软链接：
$ cp -rP dir1 dir3 $ ls -l dir3 total 0 lrwxrwxrwx 1 wjm wjm 10 Aug 6 17:07 slink -> /tmp/a.txt
假如没有明确指定-L或者-P选项，则cp的默认行为将随版本而定。
目录的硬链接
前文提到过，无法对一个目录创建硬链接。但其实目录是存在硬链接的，只是这个硬链接是系统自动创建的，而我们不能手动创建。当我们用mkdir创建一个空目录时，会发现这个目录的硬链接数为2，例如：
$ ls -dl ~ drwx------. 6 wjm wjm 4096 Aug 10 04:25 /home/wjm $ cd ~ $ mkdir mydir $ ls -dli ~ 8605 drwx------. 7 wjm wjm 4096 Aug 10 04:25 /home/wjm $ ls -dli mydir 11556 drwxrwxr-x 2 wjm wjm 4096 Aug 10 04:25 mydir
原先/home/wjm目录的硬链接数量为6，当在/home/wjm下创建了一个空目录mydir后，它的硬链接数量变成了7，而这个空目录mydir的硬链接数为2。这是为什么呢？原因是任何一个目录下，都有两个隐藏的硬链接：
ls -ali mydir total 8 11556 drwxrwxr-x 2 wjm wjm 4096 Aug 10 04:25 . 8605 drwx------. 7 wjm wjm 4096 Aug 10 04:25 ..
我们看到mydir目录下有两个隐藏的硬链接，使用ls的-a选项才能使其列出来。其中一个硬链接是“.”，指向的inode号为11556，就是mydir这个目录本身的inode号；另一个是“..”，通过inode号我们发现它指向了其父目录/home/wjm。因此，当创建了空目录mydir后，mydir的硬链接数为2，而其父目录的硬链接数加1。所以一个目录的硬链接数=其子目录数+2。
这种硬链接是系统自动为我们创建的，而当你试图手动创建一个指向目录的硬链接时，系统一定会报错阻止你这样做。为什么呢？
其实在UNIX操作系统的历史上，对目录创建硬链接曾经是允许的。但人们发现，这样做会出现很多问题，尤其是一些对目录树进行遍历操作的如fsck、find等命令无法正确执行。在《Unix高级环境编程》中提到作者Steven在自己的系统上做过实验，结果是：创建目录硬链接后，文件系统变得错误百出。因为这样做会破坏文件系统的树形结构，可能会使目录之间出现环。例如：
$ ln ~ ~/mydir/myhdir_link ln: `/home/wjm': hard link not allowed for directory $ ln -s ~ ~/mydir/myhdir_link
这里第一条命令我们试图在mydir目录下创建一个硬链接指向其父目录，然而失败了。因为这使得/home/wjm和/home/wjm/mydir两个目录之间形成一个环，我们无法再区分这两者谁是父目录谁是子目录了。然而第二条命令创建一个指向其父目录的软链接却可以成功，难道这样不是同样形成了一个环吗？
为什么软链接可以指向目录而硬链接不行呢？根本原因在于软链接实质上是一个文件，而硬链接实质上是一个目录项（dentry）。在linux系统中，每个文件(目录也是文件，软链接也是文件)都对应着一个inode结构，其中inode数据结构中包含了文件类型(目录，普通文件，符号连接文件等等)的信息，也就是说操作系统在遍历目录时可以判断出符号连接。既然可以判断出符号连接当然就可以采取一些措施来防范进入死循环了，系统在连续遇到8个符号连接后就停止遍历，这就是为什么对目录符号连接不会进入死循环的原因了。而“硬链接”本质上是“目录项”的同义词。当一个目标第一次被创建，就会为它创建一个目录项，这其实就是硬链接。大多数人常常把“硬链接”联想成为一个已有的对象创建一个额外的目录项，但其实是原来的目录项没有任何特殊，所有的硬链接都是平等的，所以Linux内核没有方法能识别出哪个是“原文件”哪个是“硬链接”。这样对于由于目录硬链接而形成的环就无法进行合适的处理。
但是根目录是一个特例。我们观察：
$ ls -dli /
2 dr-xr-xr-x. 22 root root 4096 Aug 10 00:50 /
$ ls -ali /
total 102
2 dr-xr-xr-x. 22 root root 4096 Aug 10 00:50 .
2 dr-xr-xr-x. 22 root root 4096 Aug 10 00:50 ..
... ...
可见这里根目录的inode号为2，而且根目录下的指向其父目录的隐藏硬链接（..）也指向了自身。