基本的なデータ構造として（階層的）ファイルシステムをどのように使用したのですか？
私は独学でCSの学位を持っていません。私がデータ構造について学んでいるほど、この時代において、OSの基本的なデータストレージ構造として、ファイルシステム、ディレクトリ、ファイルをどのように利用できるのでしょうか。
私はそれが単純であることを理解していますが、現在、ネイティブで利用できるオプションがもっとある可能性があるようです。私の知る限り、ファイルシステムの基本的な機能を改善するための唯一のプロジェクトはReiserFSで、ファイルのどの行が誰によって、いつ変更されたかがわかります。
たとえば、ファイルにネイティブのタグを付けることができ、画像、図、ワープロドキュメント、コードリポジトリ全体を1つのプロジェクトに属するものとしてタグ付けできるとしたら、それは非常に役立ちます。私はファイルシステムのパラダイムで立ち往生しているので、それらすべてを単一のフォルダー/ディレクトリに入れることができることはわかっていますが、それらがすでに別のディレクトリに存在し、そこにとどまる必要がある場合はどうなりますか？これを行うことができるプログラムが世の中にあることは知っていますが、なぜそれらがファイルシステムにないのですか？
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などの古いminiで非階層ファイルシステムを使用してきました。ディレクトリがありませんでした。グループとアカウントがあり、ファイルの名前は "group。account。file"のようになり、 "users.jbode.myfile1"のようになります、「dev.jbode.main」など.
現在、これらはoldシステムであり、個々のディスクスペースクォータは1メガバイト単位であったため、ものを整理するのに多くのレベルが必要だったわけではありませんが、ユーザーとプログラマの観点から見ると、階層システムは- ずっとより良い。
タグをサポートするために、現在のファイルシステム（本当に：正直に言うと、何でも）を実際に実行する必要がある場所（少なくとも一部）がわかりません。あなたがそれに取り掛かると、タグをサポートすることは、関連するいくつかの余分なデータを意味しますwithファイルですが、バイトのストリームには書き込まれませんforそのファイル。
NTFS（wideで使用されている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- can/Rフラグを使用して、代替ストリームに関する情報も表示します。たとえば、上で作成したファイルのリストは次のようになります。
03/16/2011 08:22 PM 23 test.txt
9 test.txt:tags:$DATA
1 File(s) 23 bytes