答案1
这取决于文件系统。大多数文件系统遵循传统的 Unix 设计，其中.和..是硬链接，即它们是文件系统中的实际目录条目。目录的硬链接计数为 2 + n，其中 n 是子目录的数量：即目录父目录中的条目、目录自己的.条目以及每个子目录的..条目。每次创建、删除或移入或移出目录时，硬链接计数都会更新。看为什么新目录在添加任何内容之前其硬链接计数为 2？以获得更详细的解释。
一些文件系统偏离了这一传统，特别是BTFS。
我们知道硬链接不能指向目录
这是不精确的措辞。更准确地说，您无法使用ln实用程序或link系统调用或类似方法创建到目录的硬链接，因为内核阻止您这样做。调用mkdir确实会创建到新目录的父目录的硬链接。这是创建到文件系统上的目录的新硬链接的唯一方法（相反，删除目录是删除到目录的硬链接的唯一方法）。
另请注意，将硬链接视为“指向”主文件是一种误导。与符号链接不同，硬链接不是定向的。当一个文件有多个硬链接时，它们是等效的。执行以下顺序后：
mkdir a b
touch a/file
ln a/file b/file
文件系统中没有任何东西可以成为b/file次要的a/file。这两个目录条目都引用同一个文件。它们都是文件的硬链接。
答案2
这是一个实现细节。
在符合 POSIX 的文件系统中，..其作用类似于硬链接。
但是，某些文件系统仅模拟这一点，并不实际将其存储在磁盘上。
出于功能目的，假设您没有文件系统损坏，则这种区别没有实际意义。 （如果这样做，fsck 旨在解决此问题。）
完全模拟硬链接的非 posix 失败之一是硬链接计数无法指示目录内子目录的正确数量。 optionfind选项-noleaf禁用使用此链接计数的优化。
答案3
作为补充吉尔斯的回答我认为值得关注这些词并对其进行扩展：
另请注意，将硬链接视为“指向”主文件是一种误导。
了解 Linux 中文件的概念模型非常重要每一个目录内的名称是指向可能指向数据的“索引节点”的“链接”。
这里令人困惑的是“硬链接”和“符号链接”的命名约定听起来像是同一事物的两种风格。他们不是！
常规文件是：
link -> x
| Inode -> Data
“硬链接文件”没有什么不同：
link_a -> x
| Inode -> Data
link_b -> x
但符号链接是：
original_file_name -> x
| Inode -> Data
sym_link_name -> x
| Inode -> File name "original_file_name"
那么为什么不能硬链接目录呢？
我得到的最好的解释来自这。该..条目必须保留在目录中。如果您有多个单一名称指向目录本身，则可能有多个父级，这是不可能的，因为..只能存在一次，就像目录中所有其他可能的名称只能存在一次一样。
答案4
那么，.. 真的是硬链接（如 .）吗？
不存在这样的事物(目的) 作为硬链接。
所有文件名（包括.或..）都不能是硬链接；并且所有文件名（包括.或..）都不能是非硬链接。那是因为硬链接不是这样的属性。
硬链接是抽象概念超过 1 个目录列表条目指向同一对象（inode）。这就是重新计数的概念，并且重新计数可能大于1。
事实上，.作为..这个游戏的一部分，它们总是指向一个从其他地方指向的对象；即总是有至少 2 的重新计数。