硬链接和软链接的区别

硬链接和软链接的区别在于：

一、空间占用：

1.硬链接不占用空间；创建一个新的硬链接，然后使用ls -li命令去查看文件信息。会发现新建的硬链接和源文件具有相同的inode（两者之间互为硬链接），文件大小相同。对其中一个进行编辑，另外一个的信息也会发生相同的更改。这就比较好理解硬链接是“别名”的说法了。

2.软链接会占用空间；新建一个软连接，ls -li可以看到inode和源文件不同，软连接占很少的字节数，一般显示为0.

二、删除:

1.删除源文件；硬链接不会受影响（在count>1的前提下），因为使用rm等命令删除源文件，实际上操作的仍然是一个文件名，或者说是该数据块的一个别名。只要还有其他的硬链接存在（即count>1），数据块就不会被删除。而软链接是一个独立的inode，inode中存放源文件的路径名，源文件被删除之后，软链接失效，不能打开。

三、跨文件系统：

硬链接不能跨文件系统，因为硬链接和源文件使用的相同的inode，所以如果想访问硬链接，则必须在和源文件相同的文件系统下进行。因为inode在一个文件系统中是唯一的，而两个文件系统的inode是互不相关的

软连接可以跨文件系统，因为软连接使用的是独立的inode，是根据inode中记录的路径消息来寻找源文件

四、硬链接不能是文件夹类型；假设有两个文件夹，路径分别为 /p1/d1 和 /p2/d2 ，d1和d2硬链接到同一个inode。因为d1和d2指向同一个inode，互为硬链接。则d1和d2中的内容应该一致。包括“..”。这样目录项（directory entry）实际上就是同一个值。则d1和d2是同一个目录。

如果把d1和d2作为两个目录，则在空间回收（reclamation）的时候就会出现引用环（cycle reference）。

有资料说root用户可以创建目录型的硬链接，但是在debian 6.0上试验，未能成功

还有其他操作系统有资源锁的考虑也禁止创建目录型的硬链接

 

附不能创建目录型硬链接的参考资料：

为什么不能创建目录的硬链接？

**** Hard link to a directory would create a loop inthe filesystem graph and that would really confuse the programs relying on thegraph traversal 

(e.g. fsck). 

**** Maybe you can use the mount command with --bindpara to hard link a directory.

 

-----------

Hard Link 

http://c2.com/cgi/wiki?HardLink

In a traditional UNIX filesystem, a directory is justa file that contains an association list. The entries in that list map names,which are strings, to inode numbers, which are unique file identifiers. Aninode number is essentially an on-disk pointer; the file object can beefficiently located from this number. No two objects have the same inodenumber, and no object has more than one inode number. 

The term "hard link" is essentially just asynonym for "directory entry". When an object is created for thefirst time, a directory entry is created for it as well. This is in fact a hardlink, but most people usually associate "hard linking" to be thecreation of additional directory entries for an existing object. But theoriginal entry is not special in any way; all the links are equal in the sensethat there is no way to tell which was the original. 

Directories can contain directories, of course, andthis is done by hard links as well. When a subdirectory is created, a directoryentry is created in the parent which associates the name of the subdirectorywith the newly created inode. Also, the new subdirectory object isautomatically stuffed with two entries which associate the names . and .. (dotand dotdot) with the new directory, and the parent, respectively. Therefore,the creation of a subdirectory creates a new hard link to the parent, and twonew hard links to the new object: one from the parent, and one from its own dotentry. 

Directory hard links are special. Firstly, the onlyway to create them is to create directories; the operating system functions forhard linking will not allow the target of a hard link operation to be adirectory inode. The reason for that is that it could create cycles in thefilesystem';s directory structure. Depending on the kernel, the decision toallow a directory hard link may be deferred to the filesystem moduleitself. 

[Dumb question: if it was possible two have twodirectories /p1/d1 and /p2/d2 hard linked to the same inode, what would be theresult of "cd .." in each of this directory ? --FabriceGautier] 

If you mean, what if d1 and d2 were the same inode (orreferenced the same inode, to be strictly accurate -- a directory entry merelyassociates a name with an inode) -- then the question is, what is the directoryentry ".." associated with? You';re assuming d1 and d2 are the samething. Therefore they';re only one directory, not two different directories.Therefore "they" have the same contents, including "..".When d1 or d2 is first created, ".." is created at the same time, asa hard link to the parent directory. So it basically depends on which wascreated first. Simple Directed Acyclic Graphs like this in the filesystemdon';t cause catastrophes, although they';ll create user confusion in variouscircumstances. 

Which is why you don';t create any ".."links in directories. Only "parent named X" or something like it. Thesame issue comes up in language when you switch from single dispatch tomultiple dispatch; "self" no longer has any meaning. 

In a traditional UNIX filesystem, cycles are bad fortwo reasons: firstly, the reclamation of storage is based on referencecounting, which doesn';t handle cyclic references! The only backreferences arethe .. and . entries, and these are handled as special cases. 

Secondly, backreferences in the tree structure canlead to nasty multithreading problems. In the traditional kernel design, likethe BSD kernel, inodes that are in use are represented by in-memory structurescalled vnodes. These nodes are accessed concurrently, and contain locks.Certain operations retain a lock on a directory while navigating to thesubdirectory. In a cycled graph, this can lead to two processes trying toacquire a pair of locks on the same two objects, but in an opposite order,which will deadlock the processes. These locking operations are often done in away that cannot be interrupted by a signal, so the processes will staydeadlocked until a reboot. 

There are special hacks in BSD to avoid this deadlockwhen navigating the .. reference. Basically, the lock on the originatingdirectory vnode is relinquished, the .. lock is acquired and then theoriginating directory is re-locked. Yes, it';s basically an open race. It';spossible that the original directory is deleted by the time the lock isre-acquired, for instance. 

I once implemented a cycle detection algorithm forvnode locks, to try to support cyclic hard linking in a file system for aversion of BSD, but the problem was that although the code itself workedbeautifully, it was just too hard to make the rest of the kernel cooperate. Toomany places in the kernel, in the higher layers above the filesystem drivers,simply assume that a lock will succeed, or eventually succeed, and areconsequently not prepared to correctly deal with an EDEADLK error. It';s notentirely clear, even, what to do with the information which tells you that adeadlock would occur if you were allowed to proceed. Do you abort the wholesystem call? At what level do you retry? How will applications respond tohaving random filesystem operations bail with deadlock errors. 

And so that';s about five paragraphs more than youever wanted to know about hard links. 

-- KazKylheku

 

参考来源：<http://www.oldlinux.org/oldlinux/viewthread.php?tid=765>