基本的なデータ構造として（階層的な）ファイルシステムを使用する方法

私は独学で、CSの学位を持っていません。データ構造について学べば学ぶほど、OSの基本的なデータストレージ構造として、どのようにファイルシステム、ディレクトリ、およびファイルを抱えているのでしょうか？

私はそれがシンプルであることを理解していますが、最近ではネイティブで利用可能なオプションが増えているようです。私の知る限り、ファイルシステムの基本機能を改善する唯一のプロジェクトはReiserFSでした。ReiserFSでは、誰が、いつ、ファイルのどの行が変更されたかを知ることができました。

たとえば、ファイルにネイティブタグを付けて、画像、図、ワードプロセッシングドキュメント、コードリポジトリ全体をすべて単一のプロジェクトに属するものとしてタグ付けできるとしたら、本当に役立ちます。私はファイルシステムのパラダイムに固執しているので、それらをすべて単一のフォルダー/ディレクトリに入れることができることを知っていますが、それらがすでに異なるディレクトリに存在し、そこにとどまる必要がある場合はどうなりますか？私はそこにこれを行うことができるプログラムがあることを知っていますが、なぜそれらはファイルシステムにないのですか？

RDBMSで得られるような、ファイルシステムの何らかのリレーショナル機能があれば便利です。それはVista / 7の一部であるはずだったが、それは機能リストからも外れたことを理解している。

確かに、どのプログラムでもバイナリファイルを保存でき、その中に必要なデータ構造を持つことができます。OSがファイルシステムの単純な階層を超えて、データを保存するより複雑な方法を提供できないのはなぜですか？

これから始めます：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

「ファイルシステムの単純な階層を超えて、OSがデータを格納するより複雑な方法を提供できないのはなぜですか」という簡単な答えがあります。

OSが行うには多すぎるからです。

それがライブラリとアプリケーションパッケージの目的です。

たとえば、Oracleは、Oracleツールセットで管理するファイルシステムのような機能セットを販売します。

PythonはDBMライブラリを使用して、非常に洗練されたディスク上のストレージ構造を作成します。

CouchDBとMongo（およびその他）は、データベースのような機能を提供する非常に洗練されたストレージ構造です。

要点は、OSが最小限の処理を行う必要があり、すべてがアドオンであることです。

簡単な答えは次のとおりです。毎日の人々はファイルシステムを理解しています。ファイルキャビネットを思い出させます。WebページやFatアプリについても考えてください。なぜTabsそんなに人気があると思いますか？人々は彼らと同一視し、それらを素早く理解できます。

ファイルシステムで..プロパティタグに基づいてファイルのためのDBを検索するおばあちゃんを教えようとイメージング、 おばあちゃんは、彼女がそれを置く場所のファイルは、単純であることを知っています。

WinFSを使用しても、MSがファイルシステムのルックアンドフィールを取り除くとは思いません。

ここのすべての答えには少し真実がありますが、それが完全な真実だとは思いません。

リストするのは、ほとんどの場合、ユーザーと開発者の両方が毎日見逃している機能です。

人々は、DAGベースのファイルシステムを理解する以上に、ツリーベースのファイルシステムを理解しません。

そして、拡張子と呼ばれるファイル名の哀れな付属物の言い訳は絶対にありません。それらは、その目的（ファイルの種類を識別する）に完全に不適切であるだけでなく、ユーザーの迷惑の無限のソースでもあります。

まだそれらを使用している理由は、「やる」という態度と、古いコードとの互換性を維持する必要性が混在しているためです。ファイルを保存するための新しいアプローチは、基本的なファイルI / O APIの根本的な変更を意味し、ほとんどの既存のコードを役に立たなくします。それとも、レガシーAPIを維持しながら、それらの周りをつま先で歩く必要があります。PROGRA〜1を覚えておいてください。

上記の理由から、将来は特別なアプリケーション用のより特殊なファイルシステムを保持できるかもしれませんが、現在のデスクトップおよびラップトップPCアーキテクチャは存続しますが、メタデータとその恐ろしい小さな拡張。

次に、サイドを切り替えます。

それはすべて私たちの周りにあるので、ツリーのメタファーがどれほど驚くほどパワフルなのか、私たちは本当に感謝していません。私のハードドライブには、数十万のファイルがあります。ファイルを見つけなければならない場合、たとえファイルについてほとんど知らなくても、1分以上かかることはめったにありません。ここで、構造のない同じタスク、名前の単なるフラットなリスト、無限にスクロールするものを想像してください。

しかし、すべての操作は簡単で、遠くに不気味なアクションはありません。

実際、リッチメタデータとDAGベースの階層を持つドキュメントストアを一度実装しました。（それは自由形式のDAGでさえなく、厳密に2レベルのメタ構造とドキュメントであり、レベル1またはレベル2のコレクションの子である可能性があります。したがって、非常に簡単です。）

明らかに、ドキュメント名はコレクション内で一意でなければならないという要件は維持する必要がありました。

そして、問題が流れ始めました。コレクションを開いて、ドキュメントの名前を、そのドキュメントが属している別のコレクションと衝突する名前に変更するとどうなりますか？エラーメッセージを表示しましたが、ユーザーは完全に困惑していました。（これらは、この要件を要求したユーザーとまったく同じです。）

ドキュメントを削除しようとしましたが、コレクションから削除するだけでした。そのため、まだ検索結果に表示されています。他の方法でも試してみましたが、コレクションAからドキュメントを削除し、コレクションBから魔法のように消えたと不平を言っていました。そのため、「リンク解除」操作とハード削除操作の両方が必要でした。

最終的に敗北を認めましたが、幸いなことにまだ間に合いました。

しかし、メタデータによって可能になった追加の検索ファセットは、絶対的な扱いとなりました。

正直に言うと、Mac上のファイルのメタデータにはほとんど触れません。OSX（コメントなどをサポート）を使用して過去5年間で、おそらく2つのファイルでメタデータを使用したと思います。それは悪い考えだと言っていない。

タグ付けのオーバーヘッドが私にとってどのように実用的であるかはわかりません。

私が知っている最も素晴らしいファイルシステム機能は、パーティション間で機能するファイルシステムレベルのバージョン管理システムだと思います。70年代から80年代初期にVAXenで行われましたが、なぜUnixおよびNTFS / Windowsでうまくいかなかったのかはわかりません。

HP3000やEncore / Gouldなどの古いミニの非階層ファイルシステムで作業しました。ディレクトリがありませんでした。あなたは、グループとアカウントを持っていた、とのファイルのように「と命名されたグループ。アカウント。ファイル「users.jbode.myfile1」、「dev.jbode.main」などのように、」

現在、これらは古いシステムであり、個々のディスクスペースクォータは1メガバイトでした。そのため、物を整理するのにあまり多くのレベルが必要だったわけではありませんが、ユーザーとプログラマーの観点からは、階層システムの方がはるかに優れています。

タグをサポートするために、現在のファイルシステムが実際に（編集：何でも、正直に）何をする必要があるか（少なくともいくつか）はわかりません。簡単に言うと、タグをサポートするということは、ファイルに関連付けられた余分なデータを意味しますが、そのファイルのバイトストリームには書き込まれません。

NTFSは（広く使用されている1つの例を選択するために）それで十分です。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