From: Takanori Hayashi <takanori@ohsaki.meidensha.co.jp>
Subject: [b-free 664] Re: 景気良くうんと長い実身名だ
Date: Mon, 29 Sep 1997 13:30:33 +0900
> 林です。
>
> In message <199709290238.LAA14402@hisoft.soft.hitachi.co.jp>
> "[b-free 658] Re: 景気良くうんと長い実身名だ"
> "Ryuichi Naitoh <naitoh_r@soft.hitachi.co.jp>" wrote:
> naitoh_r> > 問題になるのはパス検索です。BTRON1ファイルシステムではパス名
> naitoh_r> > からリンクを検索するシステムコール(get_lnk)があります。ここに
> naitoh_r> > 渡されるパス名は、パス区切りコードでつながれた実身名の列です。
> naitoh_r> > ファイルシステムはこれを実身名に分割して実身/仮身ネットワーク
> naitoh_r> > を辿らねばなりません。実身名が文字列(TRON多国語コード)ならば、
> naitoh_r> > 実身名中にパス区切りコードは出てこないので、パスの分割は単に
> naitoh_r> > パス区切りコードの検索ですみます。しかし、実身名に任意のTADを
> naitoh_r> > 許してしまえば、実身名中にパス区切りコードが含まれる可能性が
> naitoh_r> > あるので、TADセグメントを解釈する必要ができます。
> naitoh_r> > # BTRON2のようにパス検索をファイルシステムの外に出す方法もあるけど。
> naitoh_r>
> naitoh_r> TAD の解釈をしないとパス名区切文字を含んだファイル名を get_lnk で
> naitoh_r> 処理ができないというより、パス名区切文字を含んだファイル名を作成するこ
> naitoh_r> とはできない、ということでしょう。
>
> それは「TADにたまたまパス区切りコードと同じビット表現が
> 入っていたら実身名変更(実身作成)に失敗する」ということ?
> さすがに気持ち悪くない?
あぁ、そうか図形データが入ると任意のビット表現が入ってしまうんですね。
そうすると、どんなビットの並びでも入る可能性があるか。。。。
こればっかりは、ファイルマネージャが TAD を解釈しない限りどうしようも
ないですね。この問題は致命的かな? (え、こんなことであきらめるの?)
p----------------------------------------------------------------------q
| FROM R.Night |
| E-mail: |
| rnaitoh@st.rim.or.jp |
b----------------------------------------------------------------------d