EmmaV Asked: 2019-09-15 13:13:40 +0800 CST2019-09-15 13:13:40 +0800 CST 2019-09-15 13:13:40 +0800 CST 为什么'/'包含'..'？[复制] 772 上面没有目录/，那么里面有什么意义..呢？ filesystems 4 个回答 Voted Best Answer Kusalananda 2019-09-15T14:19:58+08:002019-09-15T14:19:58+08:00 根目录中的..条目是一种特殊情况。 从 POSIX 标准（4.13 路径名解析，其中.和..条目分别称为“点”和“点-点”）： 特殊文件名点应指其前身指定的目录。特殊文件名 dot-dot 应指其前一目录的父目录。作为一种特殊情况，在根目录中，dot-dot 可能指的是根目录本身。 添加的理由是（A.4.13 路径名解析） 文件名 dot-dot 相对于根目录的含义是实现定义的。在版本 7 中，它指的是根目录本身；这是 POSIX.1-2017 中提到的行为。在某些网络系统中，该结构/../hostname/用于引用另一台主机的根目录，而 POSIX.1 允许这种行为。 其他联网系统//hostname出于相同目的使用该结构；也就是说，使用了双首字母<slash>。[...] 因此，简而言之，POSIX 标准说每个目录都应该有.和..条目，并允许..目录条目/ 引用/目录本身（注意引用的第一个文本中的“可能”一词），但它也允许实现让它指代别的东西。 文件系统的最常见实现使/..解析为/. user 2019-09-16T06:22:11+08:002019-09-16T06:22:11+08:00 Kusalananda已经告诉过您，这是 POSIX 标准规定的行为。然而，UNIX 的历史真正开始于 1970 年代初期。POSIX只能追溯到 1980 年代后半期，整整十年半之后。在实践中，POSIX 只是指定了实现已经在做什么。 相反，UNIX 很早就支持将不同设备上的文件系统挂载到其单一的统一目录层次结构中。实际上，每个文件系统都有自己的根目录；挂载的文件系统/在任何方面都不是特别特别。（它的内容可能是，但文件系统本身不是。） 和系统调用似乎是在 1970-1971 年的 UNIX V1 中引入的（根据 The Unix Heritage Society 的 Unix Tree，V1 的日期为sysmount1971-11 ）。它们在u1.s中定义（系统调用号分别为 21 和 22）并在u7.s中实现。（PDP7 UNIX，日期为 1970-01，似乎没有任何明显的祖先）。sysumount 您可能会看到这是怎么回事：当任何文件系统都可以安装在层次结构中的任何位置时，为了避免出现特殊情况，每个目录，包括每个文件系统的根目录，都应该包含一个指向它自己的父目录。在磁盘上，将文件系统的根目录的父目录条目指向的逻辑位置是文件系统的根目录，因为在文件系统的根目录“之上”没有其他东西。只有当文件系统安装在层次结构的根目录以外的某个位置时，才会在根目录“之上”拥有一些东西的概念。 在挂载时，可以将根目录的内存副本中的“父目录”指针改写为指向挂载点目录的父目录。如果没有挂载点目录的父目录（换句话说，文件系统被挂载为/），那么就不要管那段数据（因为无论如何都可能没有其他明智的地方可以指向它）或单独处理它稍后（可能是Kusalananda 的回答中提到的/../hostname/path和案例的情况）。//hostname/path 产生的行为是，在除 之外的任何目录/中，无论它是特定文件系统的根目录还是子目录（在任何嵌套级别），都..指向该目录的父目录；在 中/，..指向/。前者感觉很自然（..总是以相同的方式工作，将您移向根目录），而后者虽然有点特殊，但至少不会明显破坏任何东西（不能比根目录本身更靠近根目录）。例如，您可以敲出任意数量../并知道这些至少不会导致错误，因为..在某些时候不存在。 mosvy 2019-09-15T13:38:14+08:002019-09-15T13:38:14+08:00 上面有一个目录/，/本身。根目录的父目录就是它自己。cd ..或者cd ../..根目录内应该让你在同一个地方，不会导致错误。 请注意，在某些文件系统中，它们既不存在.也..可能作为实际目录条目存在，它们可能只是由操作系统的虚拟文件系统层模拟。 像这样的路径/../hostname应该可以让您在一些早期的 pre-vfs 和 pre-nfs 系统（如MUNIX ）中访问另一台主机的根目录（使用“Newcastle Connection”），但我不知道有任何这样的系统仍在使用，并且源代码无处可寻。 可用的信息是高度矛盾的，但似乎部署这样一个系统的最常用方法是重新编译所有程序，以便open(2)可以在用户空间中重定向所有使用路径的调用（当时没有共享库）。 可能有数百个这样的黑客（scratchbox是最近的一个，我不高兴不得不使用），所以完全不清楚为什么他们觉得有必要在 POSIX 标准中容纳它。 countermode 2019-09-17T03:05:14+08:002019-09-17T03:05:14+08:00 除了这里提到的所有其他原因之外，还有设计简单性，这是 UNIX 众所周知的。所有目录都包含..; 特殊情况总是在黑暗中隐约出现绊倒危险（出于安全性或稳健性）。因此，与其强迫程序员在许多地方处理一种罕见的情况，不如将所有目录设计为具有.和..条目并统一处理，无需考虑发生的情况/。
根目录中的
..条目是一种特殊情况。从 POSIX 标准（4.13 路径名解析，其中
.和..条目分别称为“点”和“点-点”）：添加的理由是（A.4.13 路径名解析）
因此，简而言之，POSIX 标准说每个目录都应该有
.和..条目，并允许..目录条目/引用/目录本身（注意引用的第一个文本中的“可能”一词），但它也允许实现让它指代别的东西。文件系统的最常见实现使
/..解析为/.Kusalananda已经告诉过您，这是 POSIX 标准规定的行为。然而，UNIX 的历史真正开始于 1970 年代初期。POSIX只能追溯到 1980 年代后半期，整整十年半之后。在实践中，POSIX 只是指定了实现已经在做什么。
相反，UNIX 很早就支持将不同设备上的文件系统挂载到其单一的统一目录层次结构中。实际上，每个文件系统都有自己的根目录；挂载的文件系统
/在任何方面都不是特别特别。（它的内容可能是，但文件系统本身不是。）和系统调用似乎是在 1970-1971 年的 UNIX V1 中引入的（根据 The Unix Heritage Society 的 Unix Tree，V1 的日期为
sysmount1971-11 ）。它们在u1.s中定义（系统调用号分别为 21 和 22）并在u7.s中实现。（PDP7 UNIX，日期为 1970-01，似乎没有任何明显的祖先）。sysumount您可能会看到这是怎么回事：当任何文件系统都可以安装在层次结构中的任何位置时，为了避免出现特殊情况，每个目录，包括每个文件系统的根目录，都应该包含一个指向它自己的父目录。在磁盘上，将文件系统的根目录的父目录条目指向的逻辑位置是文件系统的根目录，因为在文件系统的根目录“之上”没有其他东西。只有当文件系统安装在层次结构的根目录以外的某个位置时，才会在根目录“之上”拥有一些东西的概念。
在挂载时，可以将根目录的内存副本中的“父目录”指针改写为指向挂载点目录的父目录。如果没有挂载点目录的父目录（换句话说，文件系统被挂载为
/），那么就不要管那段数据（因为无论如何都可能没有其他明智的地方可以指向它）或单独处理它稍后（可能是Kusalananda 的回答中提到的/../hostname/path和案例的情况）。//hostname/path产生的行为是，在除 之外的任何目录
/中，无论它是特定文件系统的根目录还是子目录（在任何嵌套级别），都..指向该目录的父目录；在 中/，..指向/。前者感觉很自然（..总是以相同的方式工作，将您移向根目录），而后者虽然有点特殊，但至少不会明显破坏任何东西（不能比根目录本身更靠近根目录）。例如，您可以敲出任意数量../并知道这些至少不会导致错误，因为..在某些时候不存在。上面有一个目录
/，/本身。根目录的父目录就是它自己。cd ..或者cd ../..根目录内应该让你在同一个地方，不会导致错误。请注意，在某些文件系统中，它们既不存在
.也..可能作为实际目录条目存在，它们可能只是由操作系统的虚拟文件系统层模拟。像这样的路径
/../hostname应该可以让您在一些早期的 pre-vfs 和 pre-nfs 系统（如MUNIX ）中访问另一台主机的根目录（使用“Newcastle Connection”），但我不知道有任何这样的系统仍在使用，并且源代码无处可寻。可用的信息是高度矛盾的，但似乎部署这样一个系统的最常用方法是重新编译所有程序，以便
open(2)可以在用户空间中重定向所有使用路径的调用（当时没有共享库）。可能有数百个这样的黑客（scratchbox是最近的一个，我不高兴不得不使用），所以完全不清楚为什么他们觉得有必要在 POSIX 标准中容纳它。
除了这里提到的所有其他原因之外，还有设计简单性，这是 UNIX 众所周知的。所有目录都包含
..; 特殊情况总是在黑暗中隐约出现绊倒危险（出于安全性或稳健性）。因此，与其强迫程序员在许多地方处理一种罕见的情况，不如将所有目录设计为具有.和..条目并统一处理，无需考虑发生的情况/。