硬链接和软链接

最近的一个项目，做的是开发者平台文件的下载。业务本身没有什么技术难度，但就在项目测试过程中发现，iOS 平台部分文件是软链接文件，在文件的存储、拷贝以及压缩各个环节都会出现问题。软链接文件夹会直接替换成为指向文件夹内容，软链接文件会出错。

兵来将挡水来土掩，首先让我们来看看什么是硬链接和软链接文件：

硬链接(hard link)：ln 源文件名 链接名

文件A是文件B的硬链接，则A的目录项中的inode节点号与B的目录项中的inode节点号相同，即一个inode节点对应两个不同的文件名，两个文件名指向同一个文件，A和B对文件系统来说是完全平等的。如果删除了其中一个，对另外一个没有影响。每增加一个文件名，inode节点上的链接数增加一，每删除一个对应的文件名，inode节点上的链接数减一，直到为0，inode节点和对应的数据块被回收。

文件和文件名是不同的东西，rm A删除的只是A这个文件名，而A对应的数据块（文件）只有在inode节点链接数减少为0的时候才会被系统回收。

创建目录时，默认会生成两个目录项："."和".."。前者的inode号码就是当前目录的inode号码，等同于当前目录的"硬链接"；后者的inode号码就是当前目录的父目录的inode号码，等同于父目录的"硬链接"。

软链接(soft link)：ln -s 源文件名 链接名

软链接也叫符号连接（Symbolic Link）。软链接文件类似于Windows的快捷方式。Linux 中常用它来解决一些库版本的问题，通常也会将一些目录层次较深的文件链接到一个更易访问的目录中

A是B的软链接（A和B都是文件名），A的目录项中的inode节点号与B的目录项中的inode节点号不相同，A和B指向的是两个不同的inode，继而指向两块不同的数据块。

然而软链接A的 inode 所指向的内容实际上是保存了一个绝对路径（B的路径名），当用户访问这个文件时，系统会自动将其替换成其所指的文件路径。

A和B之间是主从关系（B是主，A是从），如果B被删除了，A仍然存在（因为两个是不同的文件），但指向的是一个无效的链接。

对于软链接的存储，国内知名存储云服务oss 并不支持，所以源文件必须打成压缩包上传至文件服务器。对于软链接的复制，则必须使用java.nio包中的内容（另一篇文章会讲到）。而对于软链接的压缩，则java本身提供不了任何支持……最终只能用java调用命令行才解决了这个问题。