第2回　ファイル管理の工夫

ファイル管理の問題

一般的な計算機上のファイル管理法は30年ぐらい前からあまり進歩していないように思われます。現在ほとんどのパソコンやサーバで利用されている階層型ファイルシステムは、UNIXのファイルシステムの開発時にDennis Ritchieによって導入されたものですが、現在ではWindowsやMacintoshなどあらゆるパソコンで採用されてファイルシステムの標準になっており、それ以外のファイル構成を考えることは難しくなっています。URLでもUNIXのファイルシステムと同様の階層表記が採用されているため、現在はあらゆるデータにおいて「/」で親子関係を表現する階層的なデータ構造が採用されているといっても過言ではないでしょう。

階層型ファイルシステム上のファイル管理はだいたい次のような原理に基づいています。

さまざまなデータを均質なファイルとして扱う
複数のファイルをディレクトリの中にまとめることができる
ディレクトリも別のディレクトリの中に置くことができる
ファイルやディレクトリには名前そのほかの属性がある

現在は誰もがこのような階層型ファイルシステム上でファイルを管理していることになりますが、階層的ファイル管理手法にはいろいろ使いにくい点があります。

階層型ファイルシステムの構造の問題

住所表記や組織の構造など世の中のたいていの大規模データは階層的に管理されていますから、階層的なデータ構造については誰でもある程度馴染みがあるはずです。しかし、住所や組織のデータ構造は誰かがしっかり管理しているのに対し、自分の計算機の中のファイルは自分ですべて管理しなければならないという大きな違いがあります。

住所や役職のようなデータは均質なものですし階層構造がほぼ自明なので扱いやすいのですが、パソコンで扱うすべてのデータをきれいに階層的に管理するのは難しいものです。「⁠システムが使うファイル」と「自分が書いた文書」は別の場所に置いておくべきだということは理解できるとしても、どういう名前でどのような階層構造で管理するのが適切なのかを決めることは簡単ではありません。展示会でメモした資料は日付で管理するべきなのでしょうか、それとも展示会のディレクトリを作るべきなのでしょうか。その展示会で撮ったデジカメ写真は展示会のディレクトリに置くべきなのでしょうか、それともデジカメのディレクトリに置いておくべきなのでしょうか。展示会のメモは「日付」「⁠仕事」「⁠会社名」などさまざまな属性を持っているはずですが、どの属性をベースにして階層構造を構築するのが適切かは簡単に判断できません。各種の請求書を処理したい場合、請求書関連のデータは仕事別のディレクトリに置くのが良いのか、まとめて1つの「請求書」ディレクトリに置くほうが良いのかわかりません。長年にわたってデータを蓄積して初めて適切な階層構造がわかってくるかもしれません。

メールメッセージやデジカメ写真の場合はそのようなメディアごとに用意されたディレクトリ内で管理されるのが普通です。仕事のメールと遊びのメールとspamメールは同じ場所に保存されますし、仕事のために撮った写真とレジャーの写真も同じディレクトリに保存されます。「⁠仕事」をベースに構成した階層データの中でこういうデータを管理しようとすると、メッセージや写真データの複製や移動が必要になるでしょう。

ファイル属性の問題

ファイル自体を管理する方法もそれほど自明ではありません。現在のパソコンでは名前を表現する文字列（例：masui）とファイルの形式を示す拡張子文字列（例：pdf）をピリオドでつないだものをファイル名として利用するのが常識になっています。名前と拡張子を利用するという方法はもともとDECのミニコンのOSで採用されていたものですが、MS-DOSやUNIXでも同様の方法が採用された結果、現在ほぼすべてのパソコンやサーバでこの方法が使われています。ファイルにはデータ形式以外にもさまざまな属性が付随しており、ファイルのバージョン番号をファイル名の一部として利用するシステムも昔は存在しましたが、現在はデータ形式を示す拡張子だけが利用されているようです。

ファイルの属性としてはファイル形式が最も重要だと認識されているためファイル形式を示す拡張子がファイル名の一部として利用されているわけですが、これだけではもちろん十分ではありません。ファイル作成日付、ファイル更新日付、ファイルの大きさ、パーミッションなどの属性も重要になることがあります。これらの属性はファイルシステムに用意されていますが、あらゆる属性を用意しておくことはできません。前回解説したようなファイルのアクセス履歴、ファイルの重要さ、ファイルの秘密の度合いなどの属性が必要になることもありますし、ファイルシステムの機能として「2012年まで要保存」「⁠しばらく使われなければ消去」のような変わった属性も欲しいかもしれません。ファイルに関連するさまざまな属性を柔軟に管理する方法がファイルシステムには用意されていないと言えるでしょう。

ファイルを管理する手法

このように、階層型ファイルシステムの現状もファイルの現状も人間にとって十分便利だとは言えないものであり、ファイルを使った情報の整理はとかく面倒なものです。階層型ファイルシステムやファイル名のコンベンション（慣習）はすっかり標準になってしまったので、もっと良い方法があったとしても現状の手法を根本的に変えてしまうことは難しいと思われます。現状のファイルシステムを有効に利用しつつ、うまいデータ管理方法を考える必要があるでしょう。

運用をがんばる方法

階層型ファイルシステムやファイル属性の特徴を最大限に活かすように注意しながら一貫した方法で階層を構築したりファイル名を設定したりできれば、ファイルの構造の把握や名前付けに悩むことはなくなるでしょう。このようなパソコン上の情報整理術はさまざまなものが提案されていますが、既存の階層型ファイルシステムやファイル名を扱っている限りは結局のところ「人間ががんばって整理する」以上のことはできません。

付加的機能を利用する方法

ハードリンクやシンボリックリンクを併用すると階層的でないリンク構造も表現できるので、階層型ファイルシステム上で柔軟なデータ構造を実現できます。しかしOSのファイル操作機能は階層構造を前提にしていますし、複雑なデータ構造は階層構造よりも理解がしづらくなることもあります。また、リンクがループを構成すると階層が無限になってしまう可能性があるので、ループを排除しつつ階層構造を便利に拡張する手法も考案されています（参考文献1⁠）⁠。

検索システムを併用する方法

適切な階層構造やファイル名を使わなくても、検索によって必要なファイルが見つかるようになっていればファイルの構造にあまり神経質になる必要はなくなるでしょう。「⁠展示会レポート」のファイルをどこのディレクトリに格納したかを忘れてしまったとしても、展示会の名前からレポートを検索できれば困りません。また、レポートを作成した日付がわかれば、その日付を頼りにしてデジカメ写真を検索すれば展示会で撮った写真を見つけることができるでしょう。展示会の名前も日付も忘れてしまった場合は、写真に位置情報が関連付けられていれば展示会の場所の記憶をもとに写真を見つけることができるかもしれません。

不完全な情報からでも芋づる式に情報を検索できる「近傍検索システム」（⁠参考文献2）のようなものを使えば、全文検索システムがなくてもリンクをたどって目的のファイルを捜すことができます。近傍検索システムは、現在注目している情報になんらかの形で近い情報を周囲に提示することにより芋づる的検索を支援するものです。図1において「PalmWiki」のWebページを閲覧すると、内容が近いファイル／置き場所が近いファイル／作成日付が近いファイル……のように対象に近いファイルがリストされるので、ブラウザ上のクリック操作を行うだけで関連情報のリンクをたどることができるようになっています。

秘密度、重要度についての計算

現在のファイルシステムでは「ファイルの重要さ」や「ファイルの秘密さ」を示す属性が欠けています。Webからダウンロードしたファイルも自分が苦労して作ったファイルも同じ扱いを受けており、コピーも削除も同じように実行されてしまいます。がんばって作ったファイルは簡単に削除できないようになっていてもよさそうなものですが、操作をちょっと間違えると入魂のファイルであってもすぐに消失してしまいます。大事なアイデアを書いた秘密ファイルは軽々しく扱われるべきではありませんが、ファイルシステムの上では重要でないファイルと同じように扱われてしまいます。前回紹介したようなアクセス履歴を利用すれば、自分がよく参照／編集しているファイルを知ることができ、そのファイルが重要であると判断して間違いなさそうですが、画像ファイルなどの場合、重要なものなのかどうかをアクセス履歴から判定できないかもしれません。

画像の内容を調べてもそれが自分にとって重要かどうかを判定することはできませんが、誰もが持っているありふれた画像であればそれほど重要でない可能性は高いと考えられるでしょう。画像でも普通のファイルでも、それがどの程度ありふれたものなのかを調べることができればその重要度を推測することが可能だと思われます。さまざまなユーザがどのようなファイルを持っているのかという情報を共有できれば、ファイルの重要度を判断できるようになるでしょう。

たくさんの人によってソーシャルブックマークに登録されたURLは重要なサイトだと判断できるように、多くの人が、手持ちのさまざまなデータについてハッシュ値をソーシャルブックマーク的なシステムに登録するようになれば、あるデータがたくさんの人に共有されているかどうかを登録数で判定できるようになり、これをもとにして情報の重要度が判定できるようになります。複数の人から同じハッシュ値が登録されている場合は誰もが持ってるデータだと判断できるので、そのデータは重要でないということがわかります。

HashInfo.com

このような考えに基づき、手持ちのファイルのハッシュ値を登録することでデータの重要度を判断できるようにするHashInfo.comというサービスを作ってみました。各ユーザは自分のファイルシステム内のファイルのSHA1値を計算してHashInfo.comに通知します。多数のユーザが自分の手持ちファイルのハッシュ値を登録することにより、手持ちのファイルがほかのユーザとどの程度共有されているかがわかるようになります。

HashInfo.comからhashinfoコマンドをダウンロードして起動すると、次のようなヘルプが表示されます。

% hashinfo    # ヘルプを表示
% hashinfo path     # 指定されたファイル／フォルダを登録
% hashinfo -p [pat] # patにマッチするファイルを登録（locate使用）
% hashinfo -q file  # ファイルの登録数を知る
% hashinfo -h file  # ファイルのハッシュ値を知る
% hashinfo -l       # ローカルのデータベースの内容をリスト
% hashinfo -c       # ローカルのデータベースを消去

ローカルマシンでファイルを指定してhashinfoを起動すると、指定したファイルのSHA1値が計算され、値のリストがHashInfo.comに通知されます。

% date > date.txt
% hashinfo date.txt
processing date.txt...
3163e7f28bda9917532e269c21e7eb6cc5918184
Total 1 files processed
Uniq: 1, Dup: 0, Collision: 0
1 file(s) registered to hashinfo.com
%

-qオプションを指定してhashinfoを起動すると、指定したファイルが何個HashInfo.comに登録されているかがわかります。date.txtはユニークなファイルなので「1」が返ります。

% hashinfo -q date.txt
1
%

空のファイルを作ってhashinfoを起動すると、次のように空ファイルのSHA1値を計算してHashInfo.comに登録します。自分のマシンで空ファイルを処理するのは今回が初めてなので空ファイルのSHA1値をHashInfo.comに通知しますが、-qオプションで調べてみると空ファイルは7台のマシンから登録されていることがわかります。

% touch emptyfile
% hashinfo emptyfile
processing emptyfile...
da39a3ee5e6b4b0d3255bfef95601890afd80709
Total 1 files processed
Uniq: 1, Dup: 0, Collision: 0
1 file(s) registered to hashinfo.com
% hashinfo -q emptyfile
7
%

同じファイルに対して再度hashinfoを適用した場合、すでに処理済みなのでHashInfo.comへの通知は行われません。

% hashinfo emptyfile
Total 1 files processed
Uniq: 0, Dup: 1, Collision: 0
%

たくさんのユーザがHashInfo.comを利用するようになれば、ファイルがどの程度ポピュラーなものかを知ることができるので、データが重要なものかを判定する基準として利用できるようになるでしょう。

ファイルのバックアップを作成する場合、自分にとって重要かどうかを基準にバックアップするかどうか判断するのが普通ですが、HashInfo.comの共有情報を判定基準に加えることができます。誰もが持っているファイルであれば、とりあえずバックアップの対象から外しておいても大丈夫でしょう。

ファイルシステムの機能に頼らないファイル管理

編集中のファイルはファイル名を利用して管理するのが便利ですが、中身が変化しないデータはファイル名を利用するよりも属性から検索できるようにしておいたほうが便利だと思います。会議の資料を作成しているときは「戦略会議資料.doc」のようなファイル名で作業をして問題ないかもしれませんが、1年後にこの資料を探そうとしても簡単に見つからないかもしれません。「⁠戦略会議資料20100423.pdf」のようにファイル名を工夫してもあらゆる属性を記述することはできませんから、ファイル名はハッシュのような適当なものにしておいて、内容、参加者、日付、場所などを記述したデータベースにそのファイルへのリンクを登録しておくほうがよい気がしています。

このような管理手法を使えばファイルシステムの階層構造に注意する必要がなくなりますし、検索が簡単になり、関連情報間でリンクを持たせることもやりやすくなります。私は現在自前のWikiをデータベースとして利用しており、次のような手順でファイルを管理しています。

① ファイルをWeb上のリポジトリにアップロードして自動的にハッシュ値のファイル名を付加する
② Wiki内にそのファイルへのリンクを記述し、必要なコメント、タグ、ほかの情報へのリンクを記述する

現在のパソコン上のほとんどのアプリケーションは、階層型ファイルシステム上のファイルにデータを保存することが前提となっています。ファイルシステムの特徴を活用しつつ、これ以外のファイル管理手法をうまく併用するとよさそうです。

次回は、自宅でも外出先でも必要なデータに簡単にアクセスする方法について考えてみたいと思います。

参考文献: 1．George W. Furnas, Jef f Zacks. "Multitrees:enriching and reusing hierarchical structure". In Proceedings of the ACM Conference on Human Factors in Computing Systems (CHI'94), pp.330-336, 1994.; 2、増井俊之、塚田浩二、高林哲「近傍関係にもとづく情報検索システム⁠」⁠、ソフトウェア科学会インタラクティブシステムとソフトウェアXI (WISS 2003)、2003年。