我们如何将（分层）文件系统作为基本数据结构？

我是自学成才的，没有CS学位。在这个时代，我对数据结构的了解越多，我就越想知道，我们如何仍将文件系统，目录和文件作为OS上的基本数据存储结构？

我了解它的简单性，但如今看来，可能会有更多本机可用的选项。据我所知，唯一改善文件系统基本功能的项目是ReiserFS，您可以在其中知道文件的哪一行由谁以及何时更改。

例如，如果我可以对文件进行本机标记，则可以在其中标记图像，图表，文字处理文档，整个代码存储库，这些都属于一个项目，这对我真的很有帮助。由于我陷入了文件系统范式中，所以我知道可以将所有这些文件放到一个文件夹/目录中，但是如果它们已经存在于不同的目录中并且需要留在那儿呢？我知道那里有可以做到这一点的程序，但是为什么它们不在文件系统上？

很好的东西是文件系统中的某种关系功能，就像使用RDBMSes一样。我知道那应该是Vista / 7的一部分，但是那也不属于功能列表。

当然，任何程序都可以存储二进制文件并在其中具有任何数据结构，为什么操作系统除了文件系统的简单体系结构之外，不能提供更复杂的数据存储方式？

从此开始：http : //en.wikipedia.org/wiki/Unix_File_System

阅读此：http : //www.unix.org/what_is_unix/history_timeline.html

然后阅读：http : //www.amazon.com/UNIX-Filesystems-Evolution-Design-Implementation/dp/0471164836

有一个简单的答案：“为什么操作系统除了文件系统的简单层次结构之外，不能提供更复杂的数据存储方式？”

因为对于操作系统而言，这太多了。

这就是库和应用程序包的用途。

例如，Oracle将向您出售一组使用Oracle工具集管理的类似于文件系统的功能。

Python使用DBM库来创建非常复杂的磁盘存储结构。

CouchDB和Mongo（及其他）是非常复杂的存储结构，提供一些类似于数据库的功能。

关键是操作系统应该做到最少，所有都是附加组件。

简短的答案是：每天人们都了解文件系统。它使他们想起文件柜。想一想网页，甚至是胖应用，为什么Tabs会如此受欢迎？人们可以认同他们，并迅速了解他们。

图像处理试图教祖母根据属性标签在数据库中搜索文件。通过文件系统， 祖母知道该文件就是她放置文件的地方。

即使使用WinFS，我也不认为MS会摆脱文件系统的外观。

这里的每个答案都有一个小道理，但我不认为这是全部道理。

您列出的大多数功能都是用户和开发人员每天都非常想念的功能。

人们对树型文件系统的了解程度超过对基于DAG的文件系统的理解程度。

对于可扩展名的文件名，绝对没有任何借口。它们不仅完全不适合其用途（标识文件类型），而且对用户而言是无休止的麻烦。

我们仍在使用它们的原因是“会做”的态度与维护与旧代码的兼容性的真正需要的结合。一种新的文件存储方法将意味着对基本文件I / O API进行彻底的更改，从而使大多数现有代码变得无用。要么要么，要么就必须脚踏实地，维护旧版API。记住PROGRA〜1。

我认为，由于上述原因，尽管将来可以为特殊应用提供更多的专用文件系统，但是尽管当前的台式机和笔记本电脑体系结构能够幸免，但由于缺少元数据和它可怕的小扩展。

现在我要换边。

因为它周围无处不在，所以我们从不真正欣赏树隐喻的强大功能。在我的硬盘上，我有几十万个文件。如果我必须找到一个文件，即使我对该文件知之甚少，也很少会花费一分钟以上的时间。现在想象一下同一任务，没有任何结构，只是一个平面名称，不断滚动。

然而，所有操作都很简单，远距离没有诡异的动作，没有什么能让我前进。

实际上，我确实实现了一个具有丰富元数据和基于DAG的层次结构的文档存储。（它甚至不是自由格式的DAG，严格来说是一个两级元结构和文档，可以是1级或2级集合的子级。因此，这非常简单。）

显然，必须保留文档名称在集合中必须唯一的要求。

然后问题开始泛滥。如果您打开一个集合并将文档名称更改为与该文档所属的另一个集合相冲突的名称该怎么办？我们显示了一条错误消息，但用户完全感到困惑。（这些是要求此要求的用户。）

他们试图删除文档，但所做的只是将其从集合中删除。因此它仍然出现在搜索结果中。我们也尝试了另一种方法，但是他们抱怨说他们从集合A中删除了一个文档，而它却从集合B中神奇地消失了。因此，我们既需要“取消链接”又需要进行硬删除操作。

最终，我们承认失败了，所幸仍然及时。

但是，使元数据成为可能的额外搜索方面绝对有效。

老实说，在Mac上，我几乎不触摸文件中的元数据。我认为在使用OSX的最近5年（支持注释等）中，我在2个文件上使用了元数据。不说这是一个坏主意。

我只是不确定标记的开销对我来说是实用的。

我认为我所知道的最好的文件系统功能将是跨分区工作的文件系统级版本控制系统。它是在70年代和80年代初在VAXen上完成的，不确定为什么它不能在Unix和NTFS / Windows上流行。

我曾在HP3000和Encore / Gould等旧版微型硬盘上使用非分层文件系统。您没有目录；你有一组和帐户，并且文件被命名为“ 组。账户。文件 ”，如“users.jbode.myfile1”，“dev.jbode.main”，等等。

现在，这些是旧系统，其中单个磁盘空间配额只有几兆字节，因此，好像您不需要太多级别来组织您的东西，但是从用户和程序员的角度来看，分层系统要好得多。

我看不到（至少某些）当前的文件系统真正需要做很多工作来支持标签。当你下来吧，多一点支持标记手段，而不是相关的一些额外的数据与文件，但不被写入字节流的该文件。

NTFS（选择一个广泛使用的示例）可以做到这一点：就NTFS而言，文件不一定是单个字节流。在NTFS上，您可以将任意数量的数据流与单个文件名相关联。每个文件都有一个（可能是空的）没有名称的“主要流”。但是，它也可以具有任意数量的其他流，每个流都必须具有一个名称。使用此功能，将名为（例如）“标签”的流添加到现有文件，（显然足够）将标签写入该流，这确实是微不足道的。

之后是比较困难的部分：让您的工具充分利用您放置在此处的标签。理想情况下，您可能希望为它们建立索引以进行快速搜索，因此您可以执行诸如为带有特定标签的所有文件创建“虚拟目录”之类的操作。

至少从我的角度来看，文件系统已经具备了所需的功能—应该存储和检索数据，并且现在可以很好地做到这一点。利用这些数据是其他工具的工作。这些工具目前尚不存在，但支持它们的文件系统基础结构确实存在。

如果允许我愤世嫉俗片刻，我想说不可避免的是，NTFS的这一功能几乎将被完全忽略和未知。毕竟，它使用简单，不需要任何特殊的API或其他任何东西。您可以在完全可移植的C，C ++或任何其他可以指定任意文件名的文件中很好地使用它。以下是一些简短的代码来演示如何使用AFS创建文件：

#include <fstream>

int main() {
    std::ofstream out("test.txt");
    std::ofstream tag("test.txt:tags");

    out << "This is the output file";
    tag << "tag1 tag2";

    return 0;
}

而且，这是一些读取和显示标签的代码：

#include <fstream>
#include <iterator>
#include <iostream>
#include <string>

int main() { 
    std::ifstream tags("test.txt:tags");

    std::copy(std::istream_iterator<std::string>(tags),
          std::istream_iterator<std::string>(),
          std::ostream_iterator<std::string>(std::cout, " "));
    return 0;
}

一切都很简单容易。请注意，尽管我仅在其中写入了一些琐碎的数据，但是您可以将AFS像对待其他文件一样对待-所有常用的“填充”都可以与其他任何文件一样使用。在普通目录显示中，将显示的只是主要流（例如，文件显示的大小将是主要流的大小），但是如果要查看它，dir 还可以显示有关备用流的信息与/R标志。例如，上面创建的文件的清单如下所示：

03/16/2011  08:22 PM                23 test.txt
                                     9 test.txt:tags:$DATA
               1 File(s)             23 bytes