为什么根目录'/'引用了它的“父”?


6

我正在为浏览器游戏开发一个假文件系统。 我最近实现了“..”和“。”文件夹,所以每个文件夹都有对其父文件的引用。 然后我检查了我的终端,如果“/”也有这些文件夹。 实际上我很惊讶它有一个目录“..”,这显然是对它自己的引用。

这种一致性的原因还是有更好的解释?

编辑: 我基本上都在寻找记录在案的文件。


没有直接相关但也看到了 unix.stackexchange.com/questions/61984/...
deepak


大。谢谢你的链接。但我的问题仍然没有得到答案。答案都“猜测”是因为一致性。
Julian Hollmann

1
顺便说一句LFS没有说'..'和& '' tldp.org/LDP/Linux-Filesystem-Hierarchy/html/...
deepak

1
@JourneymanGeek它不会。这是我的全部观点。 “..”只是父文件夹的硬链接。如果它不存在你就无法进入它。
Julian Hollmann

Answers:


3

有这个 POSIX定义

3.144空目录

最多包含目录条目的目录 点 - 点 ,确切地说 一个链接到它 (除了自己的点条目,如果存在的话), 在点 - 点

在所有文件命令的POSIX描述中,使用不同的措辞重复该定义。
例如 命令rmdir

空目录的定义最多包含一个目录   点和点的目录条目。

对于空目录的上述复杂定义显然是在这个有趣的约定背后,其目的是避免规则的任何例外,甚至不是斜杠(/)。


5

单一UNIX规范 状态:

作为一种特殊情况,在根目录中,dot-dot可以指向根目录本身。

标准中没有说明理由。官方“为什么?”回答,你可能需要直接问肯汤普森。


我想我需要接受,谢谢。
Julian Hollmann

3

文件系统遍历。

当你在Unix系统上查看文件名时,你正在查看一个有根的树。

当您查看文件时,它位于目录中。您可以通过上一级(...)并检查您所在目录的inode来询问该目录是什么。然后重复,您可以建立自己的位置。但是当你到达根部时,就没有了。只有'这里'。通过设置 '。'和'..'为相同的值,您设置一个唯一的信号,该文件系统中没有其他目录可以拥有。它是根。

当您将文件系统挂载到另一个挂载点时 - 例如,在另一个磁盘上有/ home文件系统,您可以通过引用根文件系统上的挂载点来覆盖“..”。所以挂载的文件系统root曾经有一个'。'和'..'相同,现在有不同的价值观。

有'。'和'..'重复相同的数据是一个重要的,独特的信号,仅适用于树的顶部。这告诉遍历程序,他们可以停止寻找父节点。

我认为有相关的文件 狮子会批评Unix内核版本6 。围绕第84页,它描述了如何处理挂载点。


1

我喜欢给出的其他答案,并且会添加使得这对我有意义的部分(至少对我而言)是目录实际上是特殊类型的文件。 UNIX中的任何“特殊”类型的文件都需要使其符合其“特殊”类型分类的属性。如果没有所有这些属性,系统可能无法识别它应该是什么或可能误解它。您可以使用比如vim将目录视为文件。例如,如果你用vim查看系统中的任何目录,

$ vim ~

你会看到那个“文件”中列出的第一个未注释的东西是“../”,即这个特殊文件中列出的第一个东西是父目录,正如你所料,它的父级是一个级别“up” 。但如果你改为尝试

$ vim /

你会在第一个未注释的行上看到它说“./”而不是“../”。为什么差异以及它为什么必须在这里? “/”必须列出“父”,以符合被识别为“目录”类型的特殊文件的要求。首先没有这个列表,就好像“/”指定了不同的父级(即,“/”特殊文件中的第一个),我怀疑(但尚未确认)这会导致其中一个孩子要被解释为它的父级,在文件系统中创建一个循环,即它不再是一个有根文件的系统,而是一个循环的文件系统!换句话说,如果系统总是将“目录文件”中的第一个条目解释为“此目录的父级”,则“/”必须具有适当的第一个列表以便正确解释。


这个答案没有多大意义。是的,某些编辑器允许您通过“打开”目录来查看目录的内容。其他人没有。是的,内部目录通常表示为具有某些属性集的某种类型的“特殊”文件,以及从中引用的一些给定条目集,但我怀疑这些条目的磁盘(甚至是枚举)中的顺序是拼写出来的任何设计必须适用于不同操作系统和体系结构的标准。
a CVn

一个目录 .. 入口指向目录的父级;在那棵树的根部 没有父母。那么简单的解决方案就是拥有 .. 指向它所包含的目录。 (这也意味着当您将该文件系统挂载到非根位置时, .. 可以动态更新以指向父级;无需创建其他目录条目。)
a CVn
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.