FLAGS

筆者おかあつ 大きな区分 記事の区分 記事の一覧 検索 ツイート

2009年7月26日日曜日

(プログラム) ファイル名について (mixi05-u459989-200907260824)

ミクシ内で書かれた旧おかあつ日記を紹介します。
(プログラム) ファイル名について
2009年07月26日08:24
今日はファイル名について考えた。 「ファイル名」というものがとても不合理なものだ、と言う事はずいぶん前から思っていて、「ファイル名」というものが持っている不合理な性質が元となり、その上で構築された色々なシステムはより複雑に、その扱いはより煩雑になってしまったのではないかと思っていた。



そんなある日、ファイルのバージョン管理ソフトに分散式のものがあると言う事を知った。

バージョン管理
http://en.wikipedia.org/wiki/Revision_control

そして分散式バージョン管理のソフトに、あのリナックスの作者であるライナスが作ったものがあるらしい事を知った。 これについて調べてみた。 設計は群を抜いて素晴らしいものがあった。 すっかりほれ込んでしまった。 このライナス氏が作ったソフトは Git という名前だった。

Git
http://git-scm.com/



で、Git について調べていたら、ライナス氏も僕と同じことを考えていた事を知った。
http://git.or.cz/gitwiki/GitFaq#Whyis.22gitcommit-a.22notthedefault.3F

ここにその話が出てくる。

> Indeed, according to Linus, the real reason is more philosophical: git is a content tracker, and a file name has no meaning unless associated to its content.

超訳 : 「... 実際ライナス氏に聞いてみると、その本当の理由はもっと哲学的なものなんだそうだ。 Gitは、コンテンツ(ファイルの内容)追跡ソフトであって、ファイル名というのはその内容と結びついて初めて意味を持つものだ。」

この話は僕が考えていた事を全て含む。 また僕が考えていなかったことも書いてあった。 これが僕の興味をものすごく引いた。



ファイル名というのは実に厄介なものだ。 例えばファイルに「帳簿」とか名前をつけて保存しておいたとする。 しばらく管理を続けていくうちに、もうひとつ帳簿が必要になったりするのはよくある事だ。 でも帳簿という名前が衝突してしまうので、帳簿1・帳簿2 という風に名前を分ける必要が出てくる。 しかし「帳簿」という名前を「帳簿1」と変更するのがまた大変な作業になってしまう事がままある。

例えば、これまでの長い運用期間に「帳簿」という名前で色々なショートカットを作成してしまったとか、しかも、この「帳簿」という名前を直接参照しているプログラムもたくさん作ってしまったとか、そういう場合だ。 そうなると「帳簿」という名前を「帳簿1」と変更することに、莫大な費用が発生してしまったりする。

名前を変えるだけのために、そんな費用が発生するなら、いっそのこと我慢したほうがマシだ。 誰もがそう思う。 だから、長い運用期間を経ると、ファイルの名前と内容が一致しなくなるファイルが増えていく。 これは決して減らない。 減らないと言う事は増える一方ということだ。

すると時間がたてばたつほど、システムのメンテナンスにコストがかかるようになる。 なぜか。 ファイル名と内容を手動で管理する必要が出るためだ。例えば 「帳簿」というファイル名のものは実は「帳簿(事務)」で、「経費」というファイル名のものは都合により交際費のみが書き込まれます、というようなことが頻発し始めるとすると、一致しなくなったファイル名とその内容を、いちいちノートなどを作ってキチンと管理する必要が出てくる。 これは管理者にとってとてもわかりにくいし面倒だ。 こうやて管理の手間が増えていく。 そして、担当者が変わるときの引継ぎも難しくなっていく。



僕は、この問題の原因を次のように考えた。 ファイル名とはファイルを一意に特定する役割を果たしている。 そして、そのファイル名に人間が理解するための名前をつけている。 そのこと自体が問題なのではないだろうか。 ファイルIDとファイル名称を分離すればこの問題が解決できるのではないだろうか。 僕はそう考えた。

だけど、ライナス氏はここで違うことを考えたみたいだ。 この問題について、ライナス氏は、ファイル名の存在自体が原因だと考えたらしい。

例えば、Xという名前で”ABC”という内容のファイルがあったとする。 これをそれぞれファイルA・ファイルB・ファイルCとみっつのファイルに内容を分割したとする。 すると Xというファイルが消えて、A、B、C という名前のみっつのファイルが現れる事になる。 このとき、Xという名前と、それぞれA・B・Cという名前のファイルには何の関連も生まれない。 これは、ファイルのバージョンを関する上で、障害となってくる。

あるいは、Aという名前で「AAA」という内容のファイル、Bという名前で「BBB」という内容のファイルを作ったとする。 このとき、Aという名前のファイルを「BBB」に、Bという名前のファイルを「AAA」に変更したとする。 内容の入れ替えだ。 こういう変更も、バージョン管理する上で難しい問題となってくる。

そこでライナス氏は、ファイルの名前を使わないで、ファイルの内容だけに追跡の対象を絞ることにしたようだ。 (このことをファイルコンテントトラッキングと呼ぶ) こうすれば効率のよいファイルバージョン管理システムが出来るはずだと考えたようだ。 そうしてできあがったのが Git だ。 Gitにはファイル名に依存せずファイルの内容だけに注意してファイルの管理を行うという哲学が一貫して流れている。

ところで、ファイルの履歴保存自体も、ファイル名を中心としない内容中心の保存方法を利用しているらしい。 この考え方のことを Content Addressable Storage と呼び、この部分だけに絞って言えば、ライナス氏独自の発想というわけではないらしいことがわかってきた。
http://en.wikipedia.org/wiki/Content-addressable_storage



ところで、僕が今作ろうとしているのは、ファイルコンテントトラッカーではない。 あくまでファイル名を基準としたファイルシステムの設計変更を考えている。 それには理由がある。

コンテントトラッカーで利用されている Content Addressable Storage には完全な冪等性※が備わっている。 しかし、現代一般的に利用されているファイルシステムには、冪等性とは若干異なった相対的な性質が必要とされている。

  ※冪等性 = 冪等性というのは、同じことをしたら同じ結果が戻るという性質のことだ。
  http://ja.wikipedia.org/wiki/%E5%86%AA%E7%AD%89
  http://en.wikipedia.org/wiki/Idempotence

現代のファイルシステムは、この冪等性と若干異なる要素を持っている。 もし仮にファイルシステムが完全な冪等性を持っていとすると、非常に面倒なことになる。 例えばこういうことだ。 雑記帳.txt というファイルを作ったとする。 誰かがそのファイルを参照したとする。 そしてまたもう一度そのファイルを参照したとする。 完璧な冪等性のあるファイルシステムでは、ここで、一回目に雑記帳.txt として参照した内容は、二回目以降に参照してもまったく同じ内容である事が求められる。 つまり、完全な冪等性を持ったシステム上ではファイルを書き足したり、添削したりしてはいけないのだ。 これではとても不便だ。 だからある常識の範囲にしたがって、「内容の一意性」を確保する必要がある。

内容の一意性というのは、とてもあいまいで定義が難しいものだ。 例えるならば、こういうことだ。 あるところに田中君がいたとする。 田中君は気分屋だ。 ある日は非常に悪態をついてばかりいる悪いヤツだ。 しかしある日は非常に物腰が柔らかく丁寧な人だ。 しかし、いくら態度が変わろうとも彼が田中君であることには変わりがない。 田中君として参照される人物はその人物の状態に拠らず必ず同じ人物である。

この様なものがファイルシステムにも求められる。 つまり、ttp://xxx.com/田中/今日の出来事.html というファイル名であれば、田中君の今日の出来事が読める必要がある。 これは○月○日の日記でもなく、×月×日の日記でもなく、今日の日記である必要がある。 つまり、Content Addressable Storage とは異なり、ファイルシステムではファイル名に対して、相対的な内容を参照できる必要がある。

( これは何も難しい事ではなく、日ごろインターネットを見ていれば、しばしば見つかる。 例えば、 http://mixi.jp/の内容は、ログインしたときとしていないときで表示結果が違う。 またログインしているユーザーによって内容は異なる。 この http://mixi.jp/の動作は冪等ではない。 完璧に冪等性を持ったファイルシステムではこの動作は許されない。 これは http://mixi.jp/というファイルが、ログインしたユーザーの情報を相対的に表示するファイルであると言う事をあらわしている。 加えて内容は時間によって変化することがわかると思う。 そして過去の状態を参照する方法はない。 これは冪等性を持たないファイルシステムの欠点でもある。 )


このことを、ここではファイル名の相対性と呼ぼうと思う。

視点を変えると、この相対性という考え方は、実はファイルシステムだけに限らず、物とその名前の結びつきの関係であれば必ず持っている哲学的な性質といえる。 このことは人間の認識とも深く関わる。



そうやってファイル名というものについて今日はあれこれと考えていた。 それで、こんなことに気がついた。 実はファイルというものは、入れ物と内容の二つに分かれているわけで、僕らは日ごろ何も考えずにファイル名を変更しているが、実はファイル名変更にはふたつの意味を持っているのではないだろうか。

ファイル名を変更するとき起こることのひとつは、ある入れ物を削除して、ある入れ物を作成する事だ。 そして、もうひとつは、その入れ物に入っていたものを、その新しい入れ物に移動する事だ。 ファイル名を変更すると、このふたつが同時に起こる。 しかし、これは本来別々な動作なのではないか。

このみかたのほうが、より現実に起こっていることを的確に説明できる。 あるファイルを分割して3つのファイルに移動することも起こりえるし、ある3つのファイルをひとつのファイルに移動することも起こりえる。 これらの事は今までのファイル名を基準にした考え方では説明しきれない。 名前と内容が一致しなくなるからだ。

そして、入れ物を削除して新しく作成すると言う事は、当然、リンク切れが発生する。 他から参照されている場合、その参照が無効になってしまうからだ。

ということは次のことが考えられるのではないだろうか。

・人間にとってのファイルの名前
・そのファイル名の相対性につける名前
・そのファイル入れ物の物理的な名前
・ファイルの内容

この4つが一致している必要はない。

今日はそんな事を考えた。

コメント一覧
ねこ☆ミ。   2009年07月26日 10:25
>この様なものがファイルシステムにも求められる。 つまり、ttp://xxx.com/田中/今日の出来事.html というファイル名であれば、田中君の今日の出来事が読める必要がある。これは○月○日の日記でもなく、×月×日の日記でもなく、今日の日記である必要がある。つまり、コンテントトラッカーと異なり、ファイルシステムではファイル名に対して、相対的な内容を参照できる必要がある。

こ、、、これは、難しいなぁ。
「今日」というのは、「データ」(または「構造」)だけではなく、「アルゴリズム」(または「意味」)を含んでると思うから。

かなり外れてると思うが、自分の『妄想』では、以下の動作。


田中君が今日の日記を書いた瞬間に

1.『ファイル内容』と『物理ファイル名』と『「ファイル内容」と「物理ファイル名」の関連(※)』が保存される。

2.田中君が決めた『ファイル名』と『「物理ファイル名」と「ファイル名(※)」の関連』が保存される。

3.「ttp://xxx.com/田中/今日の出来事.html」という「名」で、アクセスできる用に『「ファイル内容」と「名」の関連』を今日までの期限付きという条件で保持する。


※1 関連はリンクと読み替えてO.K.。
※2 ここでいう『ファイル名』は、Youtubeで言えば、動画のタイトルを自分はイメージするなぁ。


上に書いたのは、「意味」に踏み込まずに実装することを想定した。
それか、3.の部分を「今日」という、意味を理解するようにアルゴリズムで踏み込むか。保持時ではなく、データ取り出し時に「名」から、ファイルの関連情報を利用して「物理ファイル名」にアクセスできるアルゴリズムを組むのか。。。



>このことを、ここではファイル名の相対性と呼ぼうと思う。

自分は
>ttp://xxx.com/田中/今日の出来事.html
でアクセスできることから、「アクセス名」と言う言葉が頭に浮かんだ。

でも、自分の想像では相対性って、「冪等」の反対の意味から来ていて、ここではその概念を表しているのだろうな。

ファイル名が意味を持っているので、単純な「名」ではなく、「意味」を指示しているので、「意味名」とかも頭に浮んだがこれは今ひとつな気がする。
おかあつ   2009年07月26日 10:41
> こ、、、これは、難しいなぁ。
ちょっと書き換えたよ。
ねこ☆ミ。   2009年07月26日 10:44
おー、自分も書き換えたくなったけど、そのままにしておこう(^-^;
おかあつ   2009年07月26日 10:46
またちょっと書き加えた。
ねこ☆ミ。   2009年07月27日 15:19
思ったことの断片的な記述となります。
きっと自分は、この問題を考えるには、まだ焦点が合っていない。


◇ファイルシステム

ファイルシステムは、どこまでが範囲なんだろう。
現時点での自分の中のイメージでは、ファイルシステムは、ごく基本的な動作をするものというイメージです。
具体的には、ファイルの作成、読込、修正、削除、検索等のAPIをイメージしてます。
「相対性」の変換は、一部、アプリケーションの仕事なのかなって思った。

例えば"今日の出来事.html"については、
1.今日の日付のファイルを探索するのはファイルシステム
2.それを"今日の出来事.html"という名前でアクセスできるようにするのは、アプリケーション
のような切り分けです。

ここに自分の根本的な勘違いがありそうな予感です。


◇「相対性1」

「相対性」で指定できる範囲はどこまでだろうか。
ファイルシステムの昨日で"今日の出来事.html"にアクセスできると仮定すると、ファイルシステムへどんな指示をすればいいのか。
"昨日の出来事.html"とか、"一昨日の出来事.html"とか、"佐藤君と遊んだ時の出来事.html"とかも指定できるのだろうか。

SQLのような汎用な手続きのようなものは難しい気がしていて、すべてプログラムを作成するのかしら。


◇「相対性2」

>視点を変えると、この相対性という考え方は、実はファイルシステムだけに限らず、物とその名前の結びつきの関係であれば必ず持っている哲学的な性質といえる。 このことは人間の認識とも深く関わる。

「ttp://xxx.com/田中/今日の出来事.html」に限っていえば、言葉がどのファイル内容(そのファイル入れ物の物理的な名前か?)を指示するかという問題なのかな。
とすれば、ここでは、一つの言葉は、ファイルを抽出するアルゴリズムを持っていて、それにより0~n個のファイル内容を指示するように思える(nは任意の自然数。)。


◇ファイルの名前

ファイルの名前って、一つのファイル内容に対してひとつなのだろうか。
楽曲があれば楽曲名は一つのように、本があれば本の題名は一つのように、一つで良いのかな。
でも、原題の他に邦題がついている楽曲や本もあるなぁ。
おかあつ   2009年07月27日 16:00
層(レイヤー)っていう概念がある。 一番有名なところで行けばネットワークの何大層とか、ああいうやつじゃないだろうか。

例えば、ハードディスクとかもそうなってる。 本当はただの磁気の円盤で、これをフォーマットという作業を通じてシリンダ・ヘッド・トラックを作成する。

で、この上にファイルシステムというのを乗っける。 シリンダ・ヘッド・トラック だけだと、ただの512バイトの細かい固定長ファイルの連鎖だけで、とても不便だけど、これにファイルシステムを乗っける事で、可変長のファイルを扱う事ができるようになる。

だけど、初期のファイルシステムは不安定な上、ファイルの最大長に厳しい制約があったので、データベースソフトなどは与えられたファイルシステム上で、更にそこに巨大なファイルの連鎖を作成することで、独自に可変長ファイルを管理するシステムが現れたりした。

こうやって、小さいシステムの上により大きなシステムを乗っけて、と言う事を繰り返す事で、今のシステムは出来上がってる。

僕が言う「ファイルシステム」というのも、この流れの中にある。 僕が言うファイルシステムというのは、そういう既存のファイルシステムの上のひとつの「レイヤー」として実装されるべきものだ。 もちろん、将来的にはもっと低いレイヤーでも実装する事ができるはずだ。



名前

あまり無意味に哲学的なことを論じるのは避けたいのだけど、名前というのは、あるものを一意に指定できれば用を成す。

だけど、この一意というのがクセモノで、どれくらい一意なのかというのはよく考えてみると中々難しい問題だ。 「犬がいる」っていえば、そりゃ犬がいるんだろうけど、どんな犬が居るのかまではわからない。 それがシェパード犬なのかゴールデンレトリバーなのかはわからない。 あるいは、それが裏のタロウなのか隣のクロなのか。

遊園地に行った.txt って言うのが、どれくらい一意なのか。 人間が意味するところの遊園地に言った.txt と コンピューターが要求する 遊園地に行った.txt の意味は大きくかけ離れている。

ネットワーク透過性を持ったファイルシステムを作ろうとするとき、いつもこの問題にあたる。 コンピューターにとっては、 遊園地に行った.txt という名前のファイルは、世界中でたった一つしか存在が許されなくなるからだ。

だから、どれくらいの一意性を持つのか、「隣の」とか「裏の」といった付属的な識別しをつけるのか(その事をネームスペースと呼んだりする)を使うのか、ネームスペースはどのような分類として作るのが適切なのか、あるいはHASH値をファイル識別子として利用するのか、あるいはランダムトークンを使うのか。 よく考える必要がある。

おかあつ   2009年07月27日 16:08
c:\Users\Tanaka\diary.txt

って言うファイル名があったとする。

これは、要するにハードディスクの中で一意な名前であればいい。

diary.txt という名前は、要するにあるディレクトリの中で一意な名前であればいい。

ディレクトリ自体の名前も 自分が所属するディレクトリの中で一意な名前であればいい。

既存のファイルシステムはこうやって「階層」を使う事で一意性を確保している。

そしてその一意性は、必ずハードディスクの中で一意、という意味だ。

もっと考える。

UNIX だと

/home/tanaka/diary.txt

という風な名前になる。 だけど、 mount というシステムがあるので、システム上の階層のどの部分にディスクを割り当てるのかは任意に決められる。

つまり UNIX の フルパスファイル名は、ハードディスク内ではなく、システム内で一意、ということが言える。 このように Windowsより一意性の精度が高い。

URLとかもいい例だ。
これはインターネット上のリソースを一意に表すことができるという意味で画期的だった。

更に URI に至っては インターネット上のリソースである必要はない。

こういう風に、名前というのはその一意性の範囲を決める闘いの歴史でもある。
おかあつ   2009年07月27日 16:31
URI
http://en.wikipedia.org/wiki/Uniform_Resource_Identifier

ちなみに、Javaのパッケージ名はVM内で一意だとおもわれがちだけど、実はクラスローダー毎に一意だ。 JAVAは、これにURLを使うことでURLと同じ一意性の広さを確保しようとしている。 (だけどとても面倒で、ほとんど守られてない)
ねこ☆ミ。   2009年07月28日 23:19
現在、下のような認識です。
良く理解していなく、思ったことを断片的に記述しています。




・人間にとってのファイルの名前
人間が実際に使用する名前。
例)映画・本のタイトル、楽曲名等。
または、現在、一般に利用しているファイル名(ディレクトリを含まない。利用する範囲の人を想定して名付けされることとなる。)
必ず一つの名前となる(?確証なし。直感的には常に一つだけかもしれないし、一言語で一つな気もする。一言語で一つの場合は、日本語で「コカコーラ」で英語で「Coca-cola」みたいな。略称で「Coke」等はファイル名とは別な気がする。)


・そのファイル名の相対性につける名前
情報取得を容易にするため、わかりやすい名前。
アルゴリズムによりファイルを動的にデータの取得が可能。

例)ttp://xxx.com/田中/今日の出来事.html

これが指示するファイル内容は一意にならないが
ttp://xxx.com/田中/今日の出来事.html
自体は一意となり、一意の意味を指示する。


・そのファイル入れ物の物理的な名前
ファイルの一意識別名

・ファイルの内容
動画・写真・音楽・文章・データ等を表すデジタルデータ




現状では、
・そのファイル入れ物の物理的な名前
については、位置透過の名前を想定しているのか、それとも、位置情報を含んでるのか、確信がありません。



巨大なデータ共有空間を考えると、
・そのファイル名の相対性につける名前
で位置透過の名前をつけるのは困難な気がする。

と、思ったが、実は、
ttp://xxx.com/田中/今日の出来事.html
は、URLではなく、URIなのか。
おかあつ   2009年07月29日 00:35
1.

>現状では、そのファイル入れ物の物理的な名前については、位置透過の名前を想定しているのか、それとも、位置情報を含んでるのか、確信がありません
> 巨大なデータ共有空間を考えると、そのファイル名の相対性につける名前で位置透過の名前をつけるのは困難な気がする。

ねこミが持っているその疑問と言うのは、本質的で、かつ既にもう答えが出てる。

http://en.wikipedia.org/wiki/Uniform_Resource_Locator
http://en.wikipedia.org/wiki/Uniform_Resource_Identifier

wikiを見ればわかるけど、 URL というのは uniform resource locator で、リソースのありかを示すもの、という意味で、 一方 URI というのは uniform resource identifier なので、リソースを識別するもの、という意味だ。

つまり、片方は識別さえ出来ればいいと言っているのに対して、一方は場所までわからないとダメだ、といってる。 このふたつのものの仕事は異なる。


2.

写像という考え方がある。
http://ja.wikipedia.org/wiki/%E5%86%99%E5%83%8F

直接は関係ないけど、覚えておくと得だと思う。



3.
名前には一意性という問題がある。

「田中一郎」って言ったとき、世界中に「田中一郎」がどれくらいの数いるかというと、多分ものすごく沢山居ると思う。つまり 「田中一郎」という名前は一意性が低い。 これに限らず人間の名前というのは 識別子としてみたとき、一意性が低い。

一方指紋などは、ほぼ一人だけの個人を特定する事が出来る。 指紋を識別子としてみると、指紋はきわめて一意性が高い。

識別子というのは、IDとも呼ばれる。 ID は identifier の略だと考えられている。


4.

URLはURIの一形態で、URIはURLを含む。

ねこ☆ミ。   2009年07月30日 11:08
なるほどなぁ。>URI、URL


以下、考えたままに書いた。
焦点が合っているかもよく分からない。
的が外れている場合は無視た方がよい。




◇名前の一意性1(集合と関数)

>「田中一郎」って言ったとき、世界中に「田中一郎」がどれくらいの数いるかというと、多分ものすごく沢山居ると思う。つまり 「田中一郎」という名前は一意性が低い。 これに限らず人間の名前というのは 識別子としてみたとき、一意性が低い。

集合論で考えれば、まず、個人の集まりである人間の集合を考える。そして、その個人に対して、個人の特徴を元に、できる限り単射となる関数を考えるということだと思う。
ここでは、たまたま人間について考えるが、人間が認知できるモノ(個体)であれば、何でも良い。

知っての通り、田中一郎では一意性が低い。
そのため、まずは、さらに知っての通りだが、名前と生年月日の組合せが一致したときに同一の人物の可能性が高いとみなす。
えっ、それでも、「日本を対象にするだけでも、一意性が低い」だって?
次は名前と生年月日が一致して同じ市に住んでいるのならば、同一の人物とみなすとしよう。
これは、かなり精度が高い。
しかし、自分は、自分の街に名前と生年月日が一緒のひとを居ることを知っている。
実際に、金融機関等のデータ上は同一の人物として扱われることが多いであろう。



◇名前の一意性2(モノの一意性)

異なる物体は、同じ空間を占めることはなく、そのため、現実世界に二つの個体があれば必ず違うモノとして識別することができる、と想う。
それにより、違う個体があれば違う名前(または識別子)をつけることができる筈である。

モノだけでなく、情報を考えても、その情報のある位置により名前をつければ、同じ情報であっても、違うモノとして識別でき、すべてのモノに違う名前をつけることができる(これはURLかな?)。


◇名前の一意性3(古典的な西洋哲学や数学の言葉と日常の言葉)

上記のような考えというのは、現実の「モノ」を「言葉」に写像できるという概念が強く影響していると想う。

日常で利用される言葉は、それとは異なる。
もっと、多様で不思議なもので、使われているように使われているし、使うように使っている。
言葉のことを言葉で考えると、それは、「言葉のことを言葉で考えた」という行為である。
それは、使われた、または、使った「言葉」そのものではない。


◇名前の一意性4(人間にとってのファイルの名前)

以下、全体的にどうなのか、分からないまま、書くので間違っている可能性は高い。

「人間にとってのファイルの名前」というのは、人間が日常の中でつける名前であれば、人がつけるままに名付けされる。
そのため、「名前の一意性1」や「名前の一意性2」で考えたような一意性を問題にできない。


おかあつ   2009年07月30日 15:21
だいたいあってるような気がする。

だけど、まぁ、なんというか、そもそも、人間がつける名前はIDとして不十分っていう事が言いたいだけで、それ以上の事はあまり考える必要がないんだけどね。

ねこ☆ミ。   2009年07月30日 22:17
結論的には、なんというか、そういうことですね。

上は、データベースの「個体(Entity)を認知」する考え方の影響をうけています。
 
出展 2009年07月26日08:24 『(プログラム) ファイル名について』