符号链接为文件提供了另一个名称，在某种程度上类似于硬链接。但是，即使文件中仍然存在符号链接，也可以删除文件。

一些例子可能会有所帮助。

创建两个包含数据的文件:

$ printf Cat > foo
$ printf Dog > bar

创建一个硬链接和软链接(又名符号链接):

$ ln foo foo-hard
$ ln -s bar bar-soft

通过增加大小以长格式列出目录内容:

ls -lrS
lrwxr-xr-x   1 user  staff        3  3 Apr 15:25 bar-soft -> bar
-rw-r--r--   2 user  staff        4  3 Apr 15:25 foo-hard
-rw-r--r--   2 user  staff        4  3 Apr 15:25 foo
-rw-r--r--   1 user  staff        4  3 Apr 15:25 bar

这告诉我们

1st column: the file mode for the soft and hard links differ soft link: lrwxr-xr-x filetype: l = symbolic link owner permissions: rwx = readable, writable, executable group permissions: r-x = readable, not writable, executable other permissions: r-x = readable, not writable, executable hard link: -rw-r--r-- filetype: - = regular file owner permissions: rw- = readable, writable, not executable group permissions: r-- = readable, not writable, not executable other permissions: r-- = readable, not writable, not executable 2nd column: number of links is higher for the hard linked files 5th column: the size of the soft link is smaller, because it's a reference as opposed to a copy last column: the symbolic link shows the linked-to file via ->

更改foo的文件名不会影响foo-hard:

$ mv foo foo-new
$ cat foo-hard
Cat

更改foo的内容反映在foo-hard中:

$ printf Dog >> foo
$ cat foo-hard
CatDog

像foo-hard这样的硬链接指向文件的inode(内容)。

这不是像bar-soft这样的软链接的情况:

$ mv bar bar-new
$ ls bar-soft
bar-soft
$ cat bar-soft  
cat: bar-soft: No such file or directory

无法找到文件的内容，因为软链接指向已更改的名称，而不是指向内容。

同样地，如果foo被删除，foo-hard仍然保存内容;如果bar被删除，bar-soft只是一个指向不存在文件的链接。

当原始文件被移动时，硬链接非常有用。例如，将文件从/bin移动到/usr/bin或/usr/local/bin。到/bin中文件的任何符号链接都将被破坏，但是硬链接(直接到文件的inode的链接)不会关心。

硬链接可能占用更少的磁盘空间，因为它们只占用一个目录条目，而符号链接需要自己的inode来存储它所指向的名称。

Hard links also take less time to resolve - symlinks can point to other symlinks that are in symlinked directories. And some of these could be on NFS or other high-latency file systems, and so could result in network traffic to resolve. Hard links, being always on the same file system, are always resolved in a single look-up, and never involve network latency (if it's a hardlink on an NFS filesystem, the NFS server would do the resolution, and it would be invisible to the client system). Sometimes this is important. Not for me, but I can imagine high-performance systems where this might be important.

I also think things like mmap(2) and even open(2) use the same functionality as hardlinks to keep a file's inode active so that even if the file gets unlink(2)ed, the inode remains to allow the process continued access, and only once the process closes it does the file really go away. This allows for much safer temporary files (if you can get the open and unlink to happen atomically, which there may be a POSIX API for that I'm not remembering, then you really have a safe temporary file) where you can read/write your data without anyone being able to access it. Well, that was true before /proc gave everyone the ability to look at your file descriptors, but that's another story.

说到这里，恢复一个在进程a中打开，但在文件系统中未链接的文件需要使用硬链接来重新创建inode链接，这样当打开该文件的进程关闭或离开时，该文件不会消失。

我对使用的两点看法:

软链接可以用来缩短长路径名，例如:

ln -s /long/folder/name/on/long/path/file.txt /short/file.txt

对/short/file.txt所做的更改将应用于原始文件。

硬链接可以用来移动大文件:

$ ls -lh /myapp/dev/
total 10G
-rw-r--r-- 2 root root 10G May 22 12:09 application.bin

ln /myapp/dev/application.bin /myapp/prd/application.bin

即时复制到不同的文件夹，原始文件(在/myapp/dev上)可以移动或删除，而不会触及/myapp/prd上的文件

硬链接和软链接可以很容易地用这张图来解释。

一个目录条目链接一个结构:

struct dentry{
    ino_t ino;
    char  name[256];
}

ino是inode的编号，name是文件名，inode结构可能是这样的:

struct inode{
      link_t nlink; 
      ...
}

例如，你创建一个文件/1，目录条目可能是这样的:

struct dentry{
     ino_t ino; /* such as 15 */
     char  name[256]; /* "1" */
} 

inode结构可能是这样的:

   struct inode{ /* inode number 15 */
         link_t nlink; /* nlink = 1 */
         ...
    }

然后你创建一个硬链接(可能是/100)，目录条目可能是这样的:

  struct dentry{
     ino_t ino; /* 15 */
     char  name[256]; /* 100 */
  }

inode结构可能是这样的:

   struct inode{ /* inode numebr 15 */
         link_t nlink; /* nlink = 2 */
         ...
    }

然后你创建一个符号链接(可能是/200)到文件1，目录条目可能是这样的:

  struct dentry{
        ino_t ino; /* such as 16 */
        char  name[256]; /* "200" */
  }

inode结构可能是这样的:

   struct inode{ /* inode number 15 */ 
         link_t nlink; /* nlink = 2 */
         ...
    }

   struct inode{ /* inode number 16 */
         link_t nlink; /* nlink = 1 */
         ...
    } /* the data of inode 16 maybe /1 or 1 */