ファイル名の名前変換の動作解析

ファイル名の名前変換の動作解析

たかはしもとのぶ <monyo@sec.rd.nttdata.co.jp>
1998/01/02 作成

たかはしもとのぶさんによる、SMB ファイル名 <-> UNIX ファイル名の名前変換(NAME MANGLING)の動作解析、およびマニュアルの誤りを指摘する報告です。

From: Motonobu Takahashi <monyo@sec.rd.nttdata.co.jp>
Message-Id: <199801011904.EAA25206@loire.ts.sec.rd.nttdata.co.jp>

To: fumiya@cij.co.jp
Cc: fumiya@yk.rim.or.jp, oota@pes.com1.fc.nec.co.jp,
        senshu@astro.yamagata-cit.ac.jp
Subject: about bugs of samba man
Content-Type: Text/Plain; charset=iso-2022-jp
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
Date: Fri, 02 Jan 1998 04:04:45 +0900


  たかはしもとのぶ@NTTデータ通信と申します。
  どうもはじめまして。

  突然のメールで申し訳ないのですが、Subject にも書きましたとおり、
samba の日本語および英語マニュアルで誤り(誤解)があるように感じましたの
で、直接ご報告致します。

  samba の ML に入っていないもので個人メールで失礼します。このメールは
自由に転送して下さい。また、私もとりあえず samba の ML に入ろうと思い
ます。

  問題の箇所は smb.conf.5 の NAME MANGLING の所です。

  私は英語があまり得意ではないのですが、もともとここの所の英文自体が誤
っているのが原因だと思い、少し調査して見ました。

  以下関連するパラメータに付いて私が調べた結果を交えて動作を説明しま
す。なお、その前に用語定義をいくつか...(^^;

  (1) case	アルファベットの大文字小文字の事。いちいち日本語で書く
		のが面倒なので

  (2) UNIX ファイル名
		case が異なる以外は同じファイル名の事。例えば、
		Makefile と makefile 等。これは単に説明の便をはかる為
                に行った定義である。
		
  (3) LFN	Microsoft 用語の Long file name の事

  (4) SFN	LFN を使えない Win16 な API や MS-DOS 等からファイルに
		アクセスする為に samba が付与するファイル名の事

  (5) 8+3 形式	いわゆる 8+3 形式を指すと考えて構わないが、case は全て
                小文字の場合も該当する。つまり、以下の文書では 
		README.TXT だけでなく readme.txt も 8+3 形式であるとみ
		なす事にする。これは単に説明の便をはかる為に行った定義
		である。

  (6) 準 8+3 形式
		LFN の中でも Readme.Txt や Mail 等のように、case の混
		在を無視すればいわゆる 8+3 形式に該当するファイルを指
		す。これは単に説明の便をはかる為に行った定義である。

  (7) Windows 系
		LAN Manager(MS-DOS) , Windows 95, Windows 98 と続く、
		Windows NT 以外の Microsoft の OS, NOS 製品

  (8) Windows NT 
		Windows NT の全てのバージョン

  それでは、以下が調査したパラメータと、私が最終的に達した設定です。

  1. UNIX ファイル名を使うディレクトリを共有する場合
    ただし、パフォーマンスは悪いと思う。
    また、いずれにしても UNIX ファイル名を使うと、Windows 系から SFN 
    でしかアクセスできないファイルが発生する。

    mangled names       = yes
    mangle case         = yes
    case sensitive      = no
    default case        = upper
    preserve case       = yes
    short preserve case = yes

  2. UNIX ファイル名を使わないディレクトリを共有する場合
    これが基本設定(^_^)

    mangled names       = yes
    mangle case         = no
    case sensitive      = no
    default case        = lower or upper (as you like)
    preserve case       = yes
    short preserve case = yes

  3. UNIX ファイル名は使っても構わないが、Windows 系からアクセスしない
    ディレクトリを共有する場合のパフォーマンスに留意した設定

    mangled names       = no
    mangle case         = no
    case sensitive      = no (yes)
    default case        = lower or upper (as you like)
    preserve case       = yes
    short preserve case = yes


  それでは、以下長文ですが、調べた結果をお送りします。

1. mangled names
  これは、LFN に対する(1/1300 の確率を無視すれば)一意な SFN を作るかど
  うかです。英文、日本文とも正しいと思います。

  補足するとすれば、以下のところです。

-----

  "mangled names = no" でも、基本的には単純に 8 文字目以降を切り捨てた
  SFN が作られます。ただ、単に切り捨てられるだけなので、当然同じファイ
  ル名が多数出現し得ます。また、ここで生成される SFN ではファイルにア
  クセスできません。

  ファイル名に "." が含まれる場合は、それが一つ目の "." で、12 文字目
  以前だったら拡張子を表す "." として認識されます。また、二つ目の "."
  以降は全て無視されます。

  ファイル名の case は、"default case = upper" の場合は、全て大文字に
  なります。
  "default case = lower" の場合は、8+3 形式と見なされるファイル名の 
  case が小文字になってしまいます。

2. case sensitive
  これは man の通りです。

  ただし、以下は注意点として、どこかに書いておくべき事ではないかと思い
ます。

-----

  Windows 系の場合、ディレクトリ名は大文字でないと操作する事ができない
  ようです。(log level = 4 で smb.log を見て確認)

  従って、"case sensitive = yes" の場合、何らかの原因で、小文字を含む
  名前しか持たないファイルができてしまうと、そのファイルにはアクセスで
  きなくなります。

  例えばコマンドプロンプトから連続して

  mkdir HOGE
  mkdir hoge
  mkdir Hoge

  とタイプした場合、コマンド自体は実行されますが、"case sensitive =
  yes" で "default case = lower" だと、設定によって、アクセスできない
  ディレクトリや、SFN でないとアクセスできないディレクトリが簡単にでき
  てしまいます。
  "case sensitive = yes" で "default case = upper" でも、SFN でしかア
  クセスできないディレクトリが簡単にできてしまいます。

  SFN でしかアクセスできないディレクトリは MS-DOS プロンプトや Win16
  API からはアクセスできますが、Explorer 等からはアクセスできないので、
  実質的に使えないでしょう。

  従って、Windows 系からのアクセスが予想される場合、"case sensitive =
  no" の設定が強く推奨されます。

  例えば上の例では、"case sensitive = yes", "default case = upper",
  "mangle case = yes", "mangled name = yes" の場合、"hoge" と "Hoge" 
  は SFN でしかアクセスできません。もし、上記で "default case = lower"

  にすると、"hoge" にはどうやってもアクセスできなくなってしまいます。
  また、ここで更に "mangled names = no" にすると、加えて "Hoge" にも
  アクセスできなくなってしまいます。理由は以下の項で説明します。
  
  また、"case sensitive = no" にしても、UNIX 側で UNIX ファイル名のファ
  イルを作成する事は可能ですので、その場合は、"case sensitive = no" で
  あっても、上記と同様の問題が発生します。

  Windows NT の場合、

  mkdir HOGE
  mkdir hoge
  mkdir Hoge

  は正常に処理されますが、各々のディレクトリにアクセスする為には、ファ
  イル名の case をきちんと入力する必要がありますので、Windows NT での
  ファイルシステムの原則と異なってきます。従って、"case sensitive =
  no" の設定が推奨されます。

  また、case sensitive は、あくまでもファイル名の case を無視するだけ
  であって、case がいり混じったファイル名を作成する事を妨げるものでは
  ありません。

3. default case
  これは man の記述の通りです。
  以下、2 項の実例と関連しますが、補足です。

-----

  "case sensitive = yes" の時は、"default case = lower" だと、8+3 形式
  のファイルは 小文字の 8+3 形式のファイル名に変換されてしまい、
  Windows 系からアクセスできなくなる不都合がありますので、Windows 系か
  らのアクセスが予想される場合は、"default case = upper" に設定する事
  を強く勧めます。

  また、"case sensitive = no" にしても、UNIX 側で UNIX ファイル名のファ
  イルを作成する事は可能で、その場合は、"case sensitive = no" であって
  も、同様の問題が発生します。

  その対処の意味では、 Windows 系からのアクセスが予想される場合は、
  "default case = upper" にしておいた方が良いでしょう。

4. mangle case
  これは、全て default case であるファイル名以外のファイル名について 
  SFN を生成するかどうかを決めるものだと書かれてますが、英語のマニュア
  ルは説明不足です。

-----

  実際は準 8+3 形式の LFN および case が default case と異なっている 
  8+3 形式のファイル名について SFN を生成するかどうかを決めるものです。
  8+3 形式や、準 8+3 でないファイルについては、"mangled name = yes" が
  指定されている限り、必ず SFN が作られます。

  "case sensitive = no" の場合は、準 8+3 形式のファイル名や 8+3 形式の 
  case 違いのファイル名は、結局 8+3 形式のファイル名とみなされますので、
  基本的に問題ないのですが、"case sensitive = yes" の場合は、"mangle
  case = no" だと、こうした ファイル名には、SFN がつかないので、
  Windows 系からアクセスできなくなってしまい

  ます。
  従って、 "case sensitive = yes" の場合で Windows 系からのアクセスが
  予想される場合は、"mangle case = yes" の設定が強く推奨されます。

  また、"case sensitive = no" にしても、UNIX 側で UNIX ファイル名のファ
  イルを作成する事は可能で、その場合は、"case sensitive = no" であって
  も、同様の問題が発生します。

  その対処の意味では、 Windows 系からのアクセスが予想される場合は、
  "mangle case = yes" にしておいた方が良いでしょう。

5. preserve case
  これは、6 項で述べる 8+3 形式でないファイル名の case を default case 
  の設定に従うか、入力したとおりにするかの設定だと書かれていますが、こ
  れは英語のマニュアルの説明不足かバグです。
  ちなみに "preserve case = yes" で入力したとおりの case になると説明
  されています。

-----

  実際は、ファイル名中の文字の case が全て同一の時以外は、常に case は
  そのままファイル名に引き継がれます。

  "case sensitive = no" の時は、ファイル名の case に関わらず、常にファ
  イル名の case は全て同一とみなされるので、結果的にマニュアル通りの動
  作をしますが、"case sensitive = yes" の時は英語のマニュアル通りの動
  作はしません。

  例えば "case sensitive = yes" で "preserve case = no" かつ "default
  case = lower" の時、ファイル名 "HOGEHOGEHOGE11", "hogehogehoge11" は、
  ファイル名の文字の case が全て同一なので "hogehogehoge11" に変換され
  ますが、"Hogehogehoge11" は、"Hogehogehoge11" のままです。

  "case sensitive = yes" で "preserve case = yes" かつ "default case =
  lower" の時、ファイル名 "IKAIKAIKA11", "Ikaikaika11", "ikaikaika11" 
  は全てそのままの case でファイル名として扱われます。

  "case sensitive = no" で "preserve case = no" かつ "default case =
  lower" の時、ファイル名 "IKAIKAIKA11", "Ikaikaika11", "ikaikaika11"

  は全て小文字に変換され、"ikaikaika11" となります。従って、最初の一つ
  以外は作成できません。

  "case sensitive = no" で "preserve case = yes" かつ "default case =
  lower" の時、ファイル名 "IKAIKAIKA11", "Ikaikaika11", "ikaikaika11" 
  は全て入力した通りの case のファイル名として扱われます。しかし、 
  "case sensitive = no" のため、最初の一つ以外は同じファイル名とみなさ
  れて作成できません。
  これは Windows 系や Windows NT のファイルシステムのデフォルトの動作
  なので、そういう観点から見れば、それほど奇異な動作ではないでしょう。

6. short preserve case
  これは、英文を読むと、8+3 形式のファイル名のケースを全て大文字にする
  か、 default case の設定に従うかのように読めますが、これは誤りで、5 
  項の preserve case と同様の英語のマニュアルの説明不足かバグに加え、
  更に英文に記述ミスがあります。

-----

  基本的に機能は 8+3 形式に該当するファイル名の case を扱うという事以
  外は 5 項の "preserve case" と同一です。
  従って、5 項と同様に "short preserve case = yes" で入力したとおりの 
  case に、 "short preserve case = no" で default case の設定になる事
  を期待されていると思います。(この時点で既にマニュアルの記述とは異なっ
  てます。)

  しかし、正しくは、ファイル名の文字の case が全て同一の時以外は、常に 
  case はそのままファイル名に引き継がれます。

  "case sensitive = no" の時は、ファイル名の case に関わらず、常にファ
  イル名の case は全て同一とみなされるので、結果的に期待される動作をし
  ますが、"case sensitive = yes" の時は異なります。

  例えば "case sensitive = yes" で "short preserve case = no" かつ 
  "default case = lower" の時、ファイル名 "HOGE11", "hoge11", は、ファ
  イル名の文字の case が全て同一なので "hoge11" に変換されますが、
  "Hoge11" は、"Hoge11" のままです。

  "case sensitive = yes" で "short preserve case = yes" かつ "default
  case = lower" の時、ファイル名 "IKAIKA11", "Ikaika11", "ikaika11" は
  全てそのままの case でファイル名として扱われます。

  "case sensitive = no" で "preserve case = no" かつ "default case =
  lower" の時、ファイル名 "IKAIKA11", "Ikaika11", "ikaika11" は、全て
  小文字に変換され、"ikaika11" となります。従って、最初の一つ以外は作
  成できません。
  
  "case sensitive = no" で "preserve case = yes" かつ "default case =
  lower" の時、ファイル名 "IKAIKA11", "Ikaika11", "ikaika11" は全て入
  力した通りの case のファイル名として扱われます。しかし、 "case
  sensitive = no" のため、最初の一つ以外は同じファイル名とみなされて作
  成できません。
  これは Windows 系や Windows NT のファイルシステムのデフォルトの動作
  なので、そういう観点から見れば、それほど奇異な動作ではないでしょう。

7. Windows 98 と encrypt password
  余談ですが、 Windows 98 の Beta2.1 で試した所、Windows NT 4.0 SP3 と
同様に password の encrypt がデフォルトになっており、
EnablePlainTextPassword をするか、"encrypt passwords = yes" をしないと
接続できませんでした。

8.  その他、どうでもいい指摘

  mangling char の日本語の man で
  "呼のみ" -> "好み"

  ですよね。ついでに気づいたので。


  それでは失礼します。

--------------------------------------------------------------------
技術開発本部 ソフトウェア技術センタ インテグレーションサポート担当
高橋 基信(たかはし もとのぶ)             monyo@sec.rd.nttdata.co.jp
--------------------------------------------------------------------