为什么将自身和父链接(。和..)存储在目录项中?


11

考虑针对某些嵌入式设备的文件系统,该文件系统只不过在分层目录结构中存储文件而已。该文件系统缺少您可能在诸如UNIX和Windows之类的系统中习惯的许多操作(例如,其访问权限完全不同,并且与存储在目录中的元数据无关)。该文件系统不允许任何类型的硬链接或软链接,因此每个文件在严格的树形结构中均具有唯一的名称。

将指向目录本身及其父目录的链接存储在代表目录的磁盘数据结构中有什么好处?

大多数UNIX文件系统在磁盘上都有...条目。我不知道他们为什么不在VFS(通用文件系统驱动程序)层处理这些问题。这是历史文物吗?是否有一个很好的理由,如果是,那么恰恰是哪个理由,因此我可以确定它是否与我的嵌入式系统有关?


我一直认为它们只是存在,因此程序可以轻松访问当前目录和父目录。有趣的问题,但是它属于这里吗?
拉斐尔

@Raphael我可以理解,如果您认为我的问题过于广泛(→“不是一个真正的问题”),或者也许是“不是建设性的”,因为它有些开放性。但是我不同意它是离题的:它是关于文件系统设计的,那怎么不应用计算机科学呢?如果您认为这是题外话,请在meta上说明您的理由。
吉尔(Gilles)'所以

@Raphael我已经编辑了我的问题,希望应该清楚我的观点是嵌入式OS设计人员的观点。感谢您的意见。
吉尔斯(Gillles)“所以-别再邪恶了”

Answers:


2

拥有指向父目录的链接对我来说很有意义。如果没有它们,则始终需要处理整个目录列表。因此,例如,/home/svick/Documents/必须将其表示为{ /, /home/, /home/svick/, /home/svick/Documents }。如果您不这样做,那么您将根本找不到父目录(否则将非常昂贵)。这不仅效率低下,而且很危险。如果您有两个重叠的此类列表,则在您移动某个目录时,它们很容易使它们失去同步。

另一方面,如果您有对父目录的引用,它会更高效,更安全。

我没有任何理由真正拥有指向当前目录的链接。如果您具有代表某个目录的结构,并且想要访问该目录,.则始终完全不需要使用。因此,我希望该.链接实际上不存在于文件系统结构中,而只是虚拟的。


2
同样的话:为什么要在每个文件系统中而不是在VFS层中呢?大多数Linux文件系统都具有...条目。
吉尔斯(Gilles)'所以

就像我说的,我认为它更有效。您可以只使用当前目录,并且仅在需要时访问其父目录。如果没有父链接,则始终需要从内存根目录开始将所有目录保留在整个路径中。您将需要为每个使用的条目提供该功能。
2013年

1
@svick:吉尔斯并没有比较有与没有父链接父链接。他比较了将它们包含在实际文件系统中和将它们与实际文件系统和用户空间之间的中间代码层(vfs)模拟的情况。
rgrig

2

您得到的特殊情况较少。在许多情况下,VFS可以处理“ ..”,因为它可以处理任何其他目录名。


3
如果目录是虚拟目录,则程序(我认为是用户模式)仍然可以像处理其他目录一样处理它。您实际上并不需要链接来显示存储级别。
Aryabhata 2012

1
是的,但是为什么不在VFS层处理呢?为什么会有任何关联的存储?
吉尔斯(Gilles)'“ SO-不要邪恶”

人们为什么用哨兵实现链接列表,而不是在添加/删除功能中处理空列表情况?
rgrig

@rgrig:仅当使用考虑到的链表实现的接口以对处理归纳数据结构(C,Java等)异常不利的语言编写时,才会发生这种情况。由于从用户的角度不能直接访问VFS层,因此此问题无关紧要。
斯特凡希门尼斯

@StéphaneGimenez:这个问题相关的,因为VFS 用C写的
rgrig

2

我能想象的唯一原因是以下情况:

  1. 文件系统的原始实现以相同的目录格式存在,但当时未考虑文件路径和子目录的概念(请参阅PDP-7 Unix文件系统)。

  2. 然后人们认为路径解析和子目录将很有用!

  3. 为了保持与较早实现的一定程度的向后兼容性,决定将.and ..像其他任何目录一样存储在磁盘上。

因此,也许只是为了与40年历史的软件向后兼容,我们留下了那些无用的人工制品吗?可信的情况?


注意:将这些条目添加到目录列表中也不是完全愚蠢的,因为无论如何您都需要将真正的父目录的inode号存储在某个地方(请记住,此时允许目录上的硬链接),以及对您的引用的引用自己的inode号可能是一个很好的检查方法。


1

我没有看到一个理由实施...在任水平,而不是其他。但是,如果您将目标锁定在嵌入式系统上,那么可以节省的任何层都可以赚到美元,因此尝试并实现尽可能低的一切可能很有意义。

至于.and 的一般需求..,如果没有它们,您将如何表达相对路径?至少..对于离开当前子树的路径是必不可少的。如果您不需要这样的路径(也许树是编码访问权限的原始方法?),则不需要..

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.