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にたまたまパス区切りコードと同じビット表現が
入っていたら実身名変更(実身作成)に失敗する」ということ?
さすがに気持ち悪くない?
naitoh_r> UNIX でも '/' を含んだファイルは作れませんよね?
それは'/'を含まない文字列という仕様だったら問題はないの
では? 日本語ファイル名を許していて日本語文字の中に'/'と
同じコードが混じっているとファイルができないというなら
問題ありだけど。
# EUCを使っている限りは日本語文字に'/'のコードは入らないけど。
--- 林(takanori@ohsaki.meidensha.co.jp)