linux硬连接只能连接文件，不能连接目录；

 

1、硬连接

参考《鸟哥的Linux私房菜》，首先hard link只能在单一文件系统中进行(因为硬连接文件名关联的inode节点号是相对于文件系统的，不同文件系统|磁盘分区的inode号将会重复)。

图片示例：[root@study ~]# ln /etc/crontab ./

实体链接(《鸟哥的Linux私房菜》第四版)

文件的硬连接，是在LINK_NAME硬连接文件所在目录的block中新建“硬连接文件名”并将对应inode节点号指定为TARGET目标文件的inode节点，只是新增了目录block中【"硬连接文件名"-inode号】这样一条记录；

手册里看到有选项允许超级用户尝试硬连接目录，但也提示说可能由于系统限制而失败，即使是对超级用户。

尝试：

如果要创建~/Files/temp1目录的硬连接~/Files/temp1_hd，我天真地猜测是在上层目录~/Files的文件名列表block中新建一个“硬连接目录”的记录，并将源目录的inode节点号赋给此“硬连接目录”，那样只要具有“硬连接目录”上层目录~/Files的rw权限，对“硬连接目录”的rwx与列表显示权限的操作就等同于对源目录的操作，即下图中红色式样。

但按照《鸟哥的Linux私房菜》的解读：“不能hard link到目录又是怎么回事呢？这是因为如果使用hard link链接到目录时，链接的数据需要连同被链接目录底下的所有数据都建立链接，举例来说，如果你要将~/Files/temp1使用实体链接建立一个~/Files/temp1_hd的目录时，那么在~/Files/temp1_hd底下的所有档名同时都与~/Files/temp1底下的档名要建立hard link的而不是仅连结到~/Files/temp_hd与~/Files/temp1而已。并且，未来如果需要在~/Files/temp1_hd底下建立新文件时，连带的~/Files/temp1底下的数据又得要建立一次hard link，因此造成环境相当大的复杂度。所以，目前hard link对于目录暂时还是不支持的啊！”说明centos的xfs、ext4文件系统尝试建立目录的硬连接时，是采用图中蓝色式样，相当于创建了一个新的目录，有实体的目录文件名列表block，目录中的文件(名)均作为源目录中文件的硬连接，而子目录应该也会对应创建子目录，有实体的目录文件名列表block，子目录中的文件又要作为源目录子目录中对应文件的硬连接，相当于recursive递归地创建源目录层级内所有文件的硬连接，这确实很复杂，并且要做到目录内硬连接文件与源文件的关联增、删、改，确实复杂。

再次参考骏马金龙《inode基础知识——硬链接》：

为什么文件系统自己创建好了目录的硬链接(目录data block中子目录名——子目录inode条目，以及目录data block中./自身目录名——自身inode条目，以及目录data block中../父目录名——父目录inode条目)就不允许人为创建呢？从"."和".."目录条目的用法上考虑，如果当前目录为/usr，我们可以使用"./local"来表示/usr/local，但是如果我们人为创建了/usr目录的硬链接/temp/usr_hd，难道我们也要使用"/temp/usr_hd/local"来表示"/usr/local"么？这其实已经是软链接的作用了(访问软链接就是按原文件的路径去访问原文件)。若要将其认为是硬链接的功能，这必将导致硬链接维护的混乱。

不过，通过mount工具的"--bind"选项，可以将一个目录挂载到另一个目录下，实现"伪硬链接"，他们的内容和inode号是完全相同的：

可以看到，将/media/haypin/DefineLoadPoint目录挂载到/home/haypin/sda8_bind目录下后，二者的目录文件inode号是一样的，/media/haypin/DefineLoadPoint目录的硬链接数也2+1=3，相当于实现了"硬链接"。

总之，记住“只能创建文件的硬连接而不能创建目录的硬连接”就对了！

1.1硬链接源文件的删除

每创建一个文件的硬链接，实质上是多一个指向该inode记录的inode指针，并且硬链接数+1；

删除文件的实质是删除该文件所在目录data block中对应的inode行(不仅是删除硬链接，删除所有文件都是如此)，所以也是减少硬链接次数，由于block指针是存储在inode中的，所以不是真的删除数据，如果仍有其他inode指针(实际上是由inode号计算出inode在inode table中的偏移量从而实现寻址)链接到该inode，那么该文件的block指针仍然是可用的。当硬链接次数为1时再删除文件就是真的删除文件了，出此时inode记录中的block指针也将被删除，inode号与block号都将回收到inode bitmap、block bitmap。这机制像极了C++中的共享指针shared_ptr<T> ptr(new T)，当索引数为0时(相当于此处硬链接数删除至0个时)，被索引的动态内存(文件inode项、inode号、block号)才被释放，只是资源被释放，在物理磁盘上，此时的原动态内存内容(block块内容)在被其他指针(文件inode)所指向前都还维持原状，没被祸祸呢，我想这也是磁盘文件误删恢复的前提条件，借助文件系统日志可以回朔到原来的状态。

2、符号连接(软连接)

选项为-s

图片示例：[root@study ~]# ln -s /etc/crontab crontab2

符号链接(软链接)《鸟哥的Linux私房菜》

(符号链接)软链接虽然是新建了一个软链接文件，但软链接文件数据块data block(if exists,when length of target path-string acceed 60 Bytes,filesystem will give a data-block to inode,;if not,only the inode itself can record the target path-string)中只存储了其链接到的文件的文件名而已("/etc/crontab"共12个一字节字符)，然后根据软链接文件属性"l"+存储的链接文件名，链接到被链接文件所在目录的inode——文件名列表block块，接下来查找被链接文件名——inode，从而读取到被链接文件的数据块data block。

转载《符号链接存储方式》：

软连接之所以也被称为特殊文件的原因是：它一般情况下不占用data block，仅仅通过它对应的inode记录(软连接文件自己的inode table表项)就能将其信息描述完成；符号链接的大小是其指向目标路径占用的字符个数，例如某个符号链接的指向方式为“rmt--> ../sbin/rmt”，则其文件大小显示为11字节；只有当符号链接指向的目标的路径名较长（60个字节）时文件系统才会划分一个data block给它；它的权限如何也不重要，因它只是一个通过路径层层访问原文件的，最终决定是否能读写执行的权限由原文件决定，所以很可能ls -l查看到的符号链接权限为777（这不是原文件的权限，只是软链接文件的权限！）。

    注意。软链接本来存储block指针的地方当目标路径名少于60个字节时存储的是目标文件名。也就是说，链接文件的一切都依赖于其目标文件名。这就解释了为什么/mnt的软链接/tmp/mnt在/mnt挂载文件系统后，通过软链接就能进入/mnt所挂载的文件系统。究其原因，还是因为其目标文件名“/mnt”并没有改变。

需要留意的是，1、符号链接与Windows的快捷方式可以划上等号，由符号链接所建立的文件是一个独立的新文件，所以会占用inode与block；2、而文件硬链接则是在创建硬连接所在目录的文件名列表block中增加一条源文件名——源文件inode的记录，并不新建文件或消耗额外空间，只有当为了增加该条记录而给目录文件名列表block分配新的block时才会造成空间消费；3、可以为目录创建软链接，此时软链接文件将链接到源目录的上层目录的inode——文件名列表block；4、硬连接直接指向文件的inode——元数据data block，软连接指向源文件或源目录所在目录的inode——文件名列表block