linux目录硬连接,linux为什么不能给目录做硬链接

该楼层疑似违规已被系统折叠 隐藏此楼查看此楼

issue comes up in language when you switch from single dispatch to multiple dispatch "self" no longer has any

meaning.

In a traditional UNIX filesystem, cycles are bad for two reasons: firstly, the reclamation of storage is based on

reference counting, which doesn't handle cyclic references! The only backreferences are the .. and . entries, and

these are handled as special cases.

Secondly, backreferences in the tree structure can lead to nasty multithreading problems. In the traditional kernel

design, like the BSD kernel, inodes that are in use are represented by in-memory structures called vnodes. These

nodes are accessed concurrently, and contain locks. Certain operations retain a lock on a directory while navigating

to the subdirectory. In a cycled graph, this can lead to two processes trying to acquire 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

a way that cannot be interrupted by a signal, so the processes will stay deadlocked until a reboot.

There are special hacks in BSD to avoid this deadlock when navigating the .. reference. Basically, the lock on the

originating directory vnode is relinquished, the .. lock is acquired and then the originating directory is re-

locked. Yes, it's basically an open race. It's possible that the original directory is deleted by the time the lock

is re-acquired, for instance.

I once implemented a cycle detection algorithm for vnode locks, to try to support cyclic hard linking in a file

system for a version of BSD, but the problem was that although the code itself worked beautifully, it was just too

hard to make the rest of the kernel cooperate. Too many places in the kernel, in the higher layers above the

filesystem drivers, simply assume that a lock will succeed, or eventually succeed, and are consequently not prepared

to correctly deal with an EDEADLK error. It's not entirely clear, even, what to do with the information which tells

you that a deadlock would occur if you were allowed to proceed. Do you abort the whole system call? At what level do

you retry? How will applications respond to having random filesystem operations bail with deadlock errors.

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

-- KazKylheku