※ この記事は、Mac OS X 10.7.3/VMware Fusion 4.1.1/Windows 7 SP1について書かれています。
会社で使っている Windows Vista(32bit)がいろいろ不都合があって我慢できなくなったので、思い切ってiMacに変えた 。
AppleStoreでCPUだけ Core i7 の 2.8GHz にして、メモリは標準の4GBに、IO-DATAの4G×2を追加して12GBにした。
そして、VMware FusionとWindows7 Pro 64bitを購入して、インストールした。
既存のWindowsで使っていた仕事のファイルは、全てMac上に作った暗号化したsparse bundle image にコピーした。(sparse bundleにした方がTime Machineのバックアップの効率が良いと考えたのだけれど、VMwareのimageとかならともかく、仕事の細かいファイルの場合は意味がない、と言うかTimeMachineで特定のファイルのちょっと前のバージョンを取り出すとかができないことに今気づいた)
このmac上のvolumeをWindowsからVMware Fusionの共有機能を使ってmountした。
そして、VMware上のWindowsにOfficeとメーラを入れて、事務仕事はほとんどWindowsで、開発はVMware上のCentOSやUbuntuでできるようになった。
ここまで前置き1。
続いて前置き2。
プロジェクトの共有ファイルは、svnかdavに置くことになっていて、Windowsのdavの扱いはかなり怪しいのでCarotDAVと言うアプリケーションを利用している。
しかし、Macの場合はFinderの移動→サーバへ移動...でhttp:のURLを指定すれば直接davが開けて、そのまま読み書きができる。
そこでちょっとしたファイルのコピーはMacでやっていたのだが、私がdavに置いたファイルを、他の人が見るとファイル名が文字化けしていると言う。
どうも、濁点/半濁点を含むファイル名を、Macから置くとCarotDAVでは文字化けするらしい。CarotDAVで濁点/半濁点を含むファイルを置いた場合は、Macから正常に読み出せる。
(今にして思えば、こちらがNFC/NFDの問題だったのだが、このときはまだ知らなかった)
さて、いよいよ本題。
ある日、顧客から「サンプルデータ.zip」と言うファイルが届いた。Windows場ではlhaplusと言うアーカイバを愛用している。
いつものようにvmwareの共有フォルダに上記添付ファイルを置いて、lhaplusで展開しようとしたら、ファイルが見つからないと言われた。
ここから長い調査がはじまったのだが、前置き2の先入観のせいでてっきり「サンプルデータ」に「プ」と「デ」が入っているのが悪い、と思い込んでしまったせいでなかなか正解にたどり着かなかった
まずは、「mac 濁点」等で調べてみたところ、Mac OS Xの濁点ファイルがやってきた - miauの避難所と言うページがひっかかった。
Unicodeで濁点、半濁点を表すには、「プ」と「フ」+「゜」(\u309a)の2種類があり、「プ」に揃えようとするのをNFC、「フ」+「゜」に揃えようとするのをNFDと呼ぶらしい。
そして、Macのファイルシステム(HFS+)のファイル名は、積極的にNFDで正規化を行い、WindowsやLinuxは積極的には正規化を行わないが、結果としてNFCになっていると言うことがわかった。
っつーか、同じ文字を表すならバイト数が少ないほうが良いと思うんだけど、なんでMacはNFDを採用したんだろうか。
Macのターミナル上ではzshを使っているのだが、zshはこのNFC/NFDの正規化を行わないらしく、「サンプルデータ.zip」と言うファイルがあると、以下のような挙動をする。
再現テストを繰り返すうちに、以下のことがわかった。
そもそも、Windouwsにマウントした時点で、ファイル名の文字コードはUnicodeではなくMS932になっているので、その段階でNFCの正規化が行われているらしい(推測)
振り出しに戻って、じゃあ何が原因なのか考える。再現テストの結果からわかることは、ファイル名に非ASCIIが含まれている時かつ、8.3文字を超えているとき、に問題が発生すると言うこと。
そこで、8.3 filename - Wikipedia, the free encyclopediaなどを読んでいると、dirコマンドに /x とか /-n とか言うオプションがあることを知る。
早速、問題のディレクトリで実行してみると、
詳しい原因まではわからないが、lhaplusにこの辺のLFNからSFNへの変換(もしくはその逆)の問題があるのかもしれない。
とりあえず解決策を探そうと思って、VMwareの共有ではなくてMac OS X のsmb共有を使ってみた。
すると、lhaplusでも展開に成功した。
dir /x を実行してみると、
いまいち良くわからないけど、Mac OS X のsmb共有を使っておけば問題ないってこと?
会社で使っている Windows Vista(32bit)がいろいろ不都合があって我慢できなくなったので、思い切ってiMacに変えた 。
AppleStoreでCPUだけ Core i7 の 2.8GHz にして、メモリは標準の4GBに、IO-DATAの4G×2を追加して12GBにした。
そして、VMware FusionとWindows7 Pro 64bitを購入して、インストールした。
既存のWindowsで使っていた仕事のファイルは、全てMac上に作った暗号化したsparse bundle image にコピーした。(sparse bundleにした方がTime Machineのバックアップの効率が良いと考えたのだけれど、VMwareのimageとかならともかく、仕事の細かいファイルの場合は意味がない、と言うかTimeMachineで特定のファイルのちょっと前のバージョンを取り出すとかができないことに今気づいた)
このmac上のvolumeをWindowsからVMware Fusionの共有機能を使ってmountした。
そして、VMware上のWindowsにOfficeとメーラを入れて、事務仕事はほとんどWindowsで、開発はVMware上のCentOSやUbuntuでできるようになった。
ここまで前置き1。
続いて前置き2。
プロジェクトの共有ファイルは、svnかdavに置くことになっていて、Windowsのdavの扱いはかなり怪しいのでCarotDAVと言うアプリケーションを利用している。
しかし、Macの場合はFinderの移動→サーバへ移動...でhttp:のURLを指定すれば直接davが開けて、そのまま読み書きができる。
そこでちょっとしたファイルのコピーはMacでやっていたのだが、私がdavに置いたファイルを、他の人が見るとファイル名が文字化けしていると言う。
どうも、濁点/半濁点を含むファイル名を、Macから置くとCarotDAVでは文字化けするらしい。CarotDAVで濁点/半濁点を含むファイルを置いた場合は、Macから正常に読み出せる。
(今にして思えば、こちらがNFC/NFDの問題だったのだが、このときはまだ知らなかった)
さて、いよいよ本題。
ある日、顧客から「サンプルデータ.zip」と言うファイルが届いた。Windows場ではlhaplusと言うアーカイバを愛用している。
いつものようにvmwareの共有フォルダに上記添付ファイルを置いて、lhaplusで展開しようとしたら、ファイルが見つからないと言われた。
ここから長い調査がはじまったのだが、前置き2の先入観のせいでてっきり「サンプルデータ」に「プ」と「デ」が入っているのが悪い、と思い込んでしまったせいでなかなか正解にたどり着かなかった
まずは、「mac 濁点」等で調べてみたところ、Mac OS Xの濁点ファイルがやってきた - miauの避難所と言うページがひっかかった。
Unicodeで濁点、半濁点を表すには、「プ」と「フ」+「゜」(\u309a)の2種類があり、「プ」に揃えようとするのをNFC、「フ」+「゜」に揃えようとするのをNFDと呼ぶらしい。
そして、Macのファイルシステム(HFS+)のファイル名は、積極的にNFDで正規化を行い、WindowsやLinuxは積極的には正規化を行わないが、結果としてNFCになっていると言うことがわかった。
っつーか、同じ文字を表すならバイト数が少ないほうが良いと思うんだけど、なんでMacはNFDを採用したんだろうか。
Macのターミナル上ではzshを使っているのだが、zshはこのNFC/NFDの正規化を行わないらしく、「サンプルデータ.zip」と言うファイルがあると、以下のような挙動をする。
- ls サンプルデータ.zip → ヒットする
- ls サンプ<TAB> →補完されない
- ls サンフ<TAB> →補完されるが、「サンフ<309a>ルテ<3099>ータ.zip」と表示される
再現テストを繰り返すうちに、以下のことがわかった。
- サンプルデータ.zip → lhaplus で展開できない
- プ.zip → lhaplusで展開できる
- longlongarchive.zip → lhaplusで展開できる
- サンフルテータ.zip → lhaplusで展開できない
そもそも、Windouwsにマウントした時点で、ファイル名の文字コードはUnicodeではなくMS932になっているので、その段階でNFCの正規化が行われているらしい(推測)
振り出しに戻って、じゃあ何が原因なのか考える。再現テストの結果からわかることは、ファイル名に非ASCIIが含まれている時かつ、8.3文字を超えているとき、に問題が発生すると言うこと。
そこで、8.3 filename - Wikipedia, the free encyclopediaなどを読んでいると、dirコマンドに /x とか /-n とか言うオプションがあることを知る。
早速、問題のディレクトリで実行してみると、
2012/03/25 07:46 <DIR> . 2012/03/25 08:25 <DIR> .. 2012/03/24 22:15 131 LONG~CDD.ZIP longlongarchive.zip 2012/03/24 08:18 134 サンプ~~B2E.Zサンプルデ.zip 2012/03/24 08:18 134 サンプ~~B44.Zサンプルデータ.zip 2012/03/24 08:18 134 デ.zipのように表示された。
詳しい原因まではわからないが、lhaplusにこの辺のLFNからSFNへの変換(もしくはその逆)の問題があるのかもしれない。
とりあえず解決策を探そうと思って、VMwareの共有ではなくてMac OS X のsmb共有を使ってみた。
すると、lhaplusでも展開に成功した。
dir /x を実行してみると、
2012/03/25 07:46 <DIR> . 2012/03/25 08:25 <DIR> .. 2012/03/24 22:15 131 longlongarchive.zip 2012/03/24 08:18 134 サンプルデ.zip 2012/03/24 08:18 134 サンプルデータ.zip 2012/03/24 08:18 134 デ.zipのようにLFNのみが表示された。
いまいち良くわからないけど、Mac OS X のsmb共有を使っておけば問題ないってこと?
カテゴリ
Macトラックバック(0)
このブログ記事を参照しているブログ一覧: VMware Fusionのファイル共有の罠
このブログ記事に対するトラックバックURL: https://www.wizard-limit.net/cgi-bin/mt/mt-tb.cgi/2863
コメントする