为何Linux中.和..是硬链接而非软链接？有何优势？

Great question—this is one of those classic Unix/Linux filesystem details that feels counterintuitive at first, but makes perfect sense once you unpack the "why" behind it. Let’s break it down step by step:

First: Why Can’t Users Create Directory Hard Links? #

When you try to run ln /some/dir /another/link, you’ll get an error. The reason is simple: directory hard links created by users can easily create infinite loops in the filesystem tree. For example, if you linked /home/me/docs to /home/me/docs/loop, tools like find or du would get stuck traversing loop → docs → loop → docs... forever. The kernel blocks this to prevent filesystem corruption and broken utilities.

But . and .. Are Special (Kernel-Maintained) Hard Links #

The key difference here is that . and .. aren’t created by users—they’re automatically maintained by the filesystem kernel itself. The kernel knows exactly what these links point to, and filesystem traversal tools (like the ones that handle cd .. or ls .) are explicitly coded to recognize and handle them without looping. They don’t create the same problem as user-created directory hard links because their existence is controlled and expected by the system.

Why Hard Links Instead of Soft Links? #

There are three big reasons this design makes sense:

• Performance & Reliability: Hard links point directly to an inode (the core data structure representing a file/directory on disk). When you access .., the kernel can immediately jump to the parent directory’s inode without any extra lookup. Soft links, by contrast, require reading the link’s text content first, then resolving that path to an inode—adding an extra I/O step. Since . and .. are used constantly (every time you run a command with a relative path), speed and reliability matter a lot here.
• Filesystem Consistency: Directory hard links play a role in the filesystem’s link count system. A directory’s link count is equal to 2 + number of subdirectories (one link for ., one for the parent directory’s entry pointing to it, plus one for each subdirectory’s ..). This count helps the system determine if a directory is empty (when the count drops to 2, there are no subdirectories left). Soft links wouldn’t contribute to this count, breaking this core filesystem maintenance mechanism.
• History & Compatibility: When Unix was first designed, symbolic links (soft links) didn’t exist—hard links were the only link mechanism. . and .. were baked into the filesystem design early on, and keeping them as hard links ensures backward compatibility with decades-old code and tools that rely on this behavior.

At the end of the day, this design is a practical compromise: it avoids the chaos of user-created directory hard links while leveraging the speed and reliability of hard links for the two most essential directory references in the system.

内容的提问来源于stack exchange，提问作者Nir Schwartz