2008-12-28

Samba と rsync と Mac OS X

Mac OS X でネットワーク上のストレージを使うときに、Samba や rsync/rcp/scp などを混ぜて使うと困ることがある。

最近は MacBook Pro の内蔵ハードディスクが手狭になってきたので、当座の必要性の薄いファイルはなるべく外付けのディスクかネットワークジ上のファイルサーバにコピーをとることにしている。

必要性の高いファイルはなるべくローカルに置いておきたいし、ディレクトリツリーの構造はなるべくそのままでコピーをとりたいので rsync(1) を使ってアップデートコピーをしていた。最近の Mac OS X の rsync は、HFS(+) にちゃんと対応していて、リソースなどもよきに計らってコピーをしてくれて(-Eオプションを使う)、コピー先が別マシンのときは相手も Mac OS X でないと無視されるなど)非常に便利になっている。ただ、ここで若干の問題が生じることがあるのに最近気付いた。

Mac OS X の HFS(+) 上でのファイル名のエンコーディングと、Samba 上のファイル名のエンコーディングとは異なることが多い。Mac OS X 以外の OS を使ったマシン上のファイルシステムを Samba を使って Mac OS X から使っている人はだいたい知ってると思うけど、最近の Samba を使う限りはこれが問題になるいことは少ない。これは、アジアのペンギン: MacOS X とのファイル共有 に書かれているように、実際のファイル名のエンコーディングが異なっていても、ネットワーク上でやりとりされるファイル名のエンコーディングは問題ないように(ほぼ)統一されているからだそうだ。

SMB/CIFS でのファイル名のやりとりは、Linux や Windows では、非正規化 Precomposed UTF-16LE でやりとりされ、MacOS X では 正規化 Precomposed UTF-16LE でやりとりされています。

正規化処理を行っているか否かという違いはありますが、Linux、Windows、MacOS X のいずれも Precomposed UTF-16LE でファイル名のやりとりを行っていますので日本語ファイル名もほぼ問題なくファイル共有が出来ます。
ただし、ここに rsync や rcp など smb を介さないやりとりがあると問題が起こることがある。

つまりはこういうこと。rsync や rcp や scp などは、ファイル名に関してはなんの変換も行なわない。したがって、Mac OS X で UTF-8-MAC (前記リンク先では Unicode Normalization Form D (NFD) あるいは 正規化 Decomposed UTF-8 と書かれてますね)で表現されたファイル名のままコピー先にファイルが作成されてしまう。このコピーされたファイルを Mac OS X マシンから rsync や rcp を使ってアクセスする限りにおいては問題は生じない。

ところが、このファイルを samba を使ってアクセスすると、ときどき問題が起こる。

Linxu 上の Samba は、ローカルなファイル名が(やはり前記リンク先の表現を借りるなら)非正規化 Preomposed UTF-8 であることを前提にネットワーク向けには(smb経由では) Precomposed UTF-16LE に変換して、Mac OS X 上の samba クライアントと通信する。 ところが、rsync や rcp や scp でコピーされたファイルの名前はもともとの Mac OS X の HFS(+) 上にあったときと同じ UTF-8-MAC なので、これらのエンコーディング間で違いがある場合には Precomposed UTF-16LE へ正しく変換が行われない。UTF-8-MAC と Precompoesed UTF-8 の違いは主に濁点や半濁点などに見られるため(このへん理解があいまなのですが……)、これらが含まれる場合に困ったことになる。

たとえば、rsync でコピーしたファイルが、Samb を使ってファインダーから「見える」のに、実際にアクセスしてみると「存在『しない』」とされてしったり、場合によってはその存在さえ「見えなく」なってしまう。

一つ、実例を挙げてみる。今、Mac OS X 上で「ボ」というファイルを作ったとすると、Finder から見えるそのファイルは、「e3 83 9b e3 82 99」となっている(Mac OS X のhexdumpで確認。エンディアンの問題があるけど、ややこしいので以後 Linux 側でもこちらの表記に合わせることにする)。これを Finder で Linux (Ubuntu 8.04.1) 上の samba のボリュームにコピーすると、コピー先では「e3 83 9c」となっていて、Mac OS X で「ホ」+「゛」に decompose されていたものが、samba によって適切に変換されていることが分かる。もちろん、このファイルは Finder からは(samba を経由するので) decomposed されたように見えているのでファイル操作にはなんの問題も生じないし、Linux からも precomposed UTF-8 のファイル名として普通に扱える。

一方、samba を介さずに rsync を使って直接コピーを行なったとすると、Linux のファイルシステム上でもファイル名は変換されずに decompose された「e3 83 9b e3 82 99」となる。そして、このファイルのあるディレクトリを samba 経由でマウントすると、Mac OS X 側からこのファイルの名前は同じく「e3 83 9b e3 82 99」であるように見える。ところが このファイルにアクセスしようとすると、(sambaは)Linux 上にあるファイル名が前述のように「e3 83 9c」であることを期待するのに、そんなファイルは実際には存在しないという問題が起こる。この問題の現われ方はどうにも素直でなくて、実はこのファイルはファインダで「見る」ことはできるが、どうにも正しい(期待される)ファイルのようには見えなくなったりする(下図: 手前がローカルなボリュームに最初に作ったファイル。奥が samba でマウントしたボリューム上のファイル)。標準テキスト(本当は空のファイルなんだけど)のはずのものがコピーになるとエイリアスのように見えているし、メタデータはめちゃくちゃだし、しかも、このファイルはクリックしたとたんに Finder から見えなくなってしまう。


decomposed UTF-8 と precomposed UTF-8 でファイル名に違いがない場合にはこの問題は起こらない。だから、デジカメの写真を撮ったままのファイル名でバックアップするときには問題になることはないし、普段からファイル名に日本語を使わないような場合にも問題になることは少ない。

また、samba のサーバー側の文字設定(unix charset)を UTF-8-MAC に設定することがきれば(標準でこれができる Liinux は少なそうだ)、Mac OS X からそのボリュームを使う場合に限ってはこの問題は解決する。しかし、その場合でも Windows から アクセスしたり、Linux 上で直接ファイル操作を行う場合に問題が起こりそうなのは同じことだ。

結論としては 、samba でのやりとりとその他の方法でのファイルのやりとりは、(それぞれのファイルシステム上のファイル名のエンコーディングが異なる)クロスプラットフォームでは

混ぜるな危険

ということか。どちらからも全く問題のない解法は今のところはないし、rsync や rcp、scp などのようなプログラムの全てにファイル名の変換機能を付けるというのも非現実的(というか自分でやりたくない/ 自分ではできない )だし。

2008-12-26

Animoto を使ってみた

TechCrunch でも紹介されていた ANIMOTO を試してみた。

これは、写真を何枚かまとめてスライドショーというか動画を作ってくれる Web アプリで、自分の場合は iPhone 用に用意された専用アプリを使ってみた。

What I ate


なかなか楽しい。音楽は向こう(ANIMOTO)が用意したものをそのまま使っているけど、それなりにバリエーションがある。

無料版で使っていると、かなり短い動画しか作れないけど、3ドル払えば長さ無制限の動画を一つ作れるようになって、30ドルならいくつでも作れるようになる。ただし、動画の長さは音楽のファイル容量(最大10MB)で決まってしまうので、何十分もあるようなものは作れないらしいけど。

今のところちょっと残念なのが、Web アプリ版で作ったアカウントを iPhone アプリと関連付ける方法が分からないので、iPhone で作った動画を web で編集したり、なにしたりというのができないこと。なんらかの方法があるのではないかと思うんだけど、iPhone 側のアプリにアカウントの設定とかが見当たらないし、Web アプリ側でもよく分からないし。

2008-12-21

なんちゃって TimeCapsule には(場合によっては) afp が必要らしい

α700 - SONY AF100mm F2.8 Macro - Preview.app

6 x 3: なんちゃって TimeCapsule を作ってみたで、TimeMachine で使うバックアップ先に samba を使って問題ないよ、ということを書いた。しかし、場合によっては afp が必要になることもあるらしい。
Mac OS X Hints上記記事によれば、Leopard のインストール用 DVD を使ってフルレストアする場合に smb は使えないとのこと。どうやら、DVD で起動するシステムから smb 関連の機能が省かれているのがその理由。afp ならもともと含まれているのでフルレストアもできるというわけ。

だから、フルレストアをしない場合は、smb でも大丈夫。コメントには、「クリーンインストールしてから移行アシスタントで TimeMachine から必要なものをごっそり持ってくる(超訳)」という手段も書かれている。

また、コメントに nfs なら大丈夫かもと書かれているのもあって、これは機会があれば試してみたいと思う(Mac OS X で nfs マウントするのは実は簡単。unmount までの時間の設定が 3600 秒になっているので、Mac を常に持ち運んで使っているような場合は短くしておくほうがいいかも)。

2008-12-20

なんちゃって TimeCapsule を作ってみた。

前からやろう、やろうと思いっていた「なんちゃって」Time Capsule を作ってみた。

参考にしたのは主に次の二つのサイト。

どちらもリモートのボリューム上のスパースバンドル・ディスクイメージをバックアップ先に使うのは同じで、それを TimeMachine が使えるようにする手順が違うだけ。

また、後者では afp が必須で smb だと駄目なように書いてあるけど、うちでは samba を使って今のところ問題なく動いているようだ。もしかしたら、samba の設定によって変わってくるのかもしれない。

というわけで、簡単にまとめてみる。

1. バックアップのディスクを用意する

バックアップを置くボリュームは、おうちサーバの openSUSE 10.3 上の samba。新しく買ってきたディスクをつないで、ファイルシステムを作って適当なところにマウントしておく(ちなみに今回は reiserfs を利用)。さらに該当ディレクトリを samba の設定で、Mac OS X からマウントできるようにしておく。

2. 実際のバックアップ先となるイメージを作る

上のリンク先にあるような手順で(どちらでも同じ)、スパースバンドル・ディスクイメージを作成する。ファイル名は、「コンピュータ名_MACアドレス.sparsebundle」のようにしておくこと。このとき、MACアドレスの Octet 区切の 「:」や「-」は入れない。例えば、コンピュータ名が「macbook.local」で MAC アドレスが 「00:23:32:ab:cd:ef」の場合は、「macbook.local_002332abcdef.sparsebundle」となる。リンク先にあるようにサイズの変更を忘れないように。

3. Mac 側でリモートボリュームへの TimeMachine を有効にする

自分は iTimeMachine を使う方法で行なったが、Terminal で「defaults write com.apple.systempreferences TMShowUnsupportedNetworkVolumes 1」する方法でもたぶん大丈夫だと思う(実際 iTimeMachine での設定後に TMShowUnsupportedNetworkVolumes が "1" に設定されているのを確認したが、その他になにをやっているのかは未確認)。それが済んだら、システム環境設定の TimeMachine パネルの「ディスクを変更」で、バックアップ先を設定しておく。

以上でおしまい。本物の TimeCapsule でもそうらしいけど最初のバックアップにはそれなりの時間がかかるので、寝る前に仕込んでおくのがいいと思う。また、次からは該当ボリュームをマウントしておかなくても必要に応じて勝手にマウントしてくれるので(使ったことがないけど)本物の TimeCapsule と使い勝手は変わらない(と思う)。

参考のために、TimeMachine 時のログを抜粋しておく(MACアドレス該当部分は「XXXXXXXXXXXX」で置き換えてある)。
オフトピだけど、下の blockquote 要素中の pre 要素に style="overflow: auto" してあるのに、Safari だとスクロールバーが出ないな……
Dec 19 01:13:07 mbp15 /System/Library/CoreServices/backupd[11787]: Starting standard backup
Dec 19 01:13:07 mbp15 /System/Library/CoreServices/backupd[11787]: Network volume mounted at: /Volumes/timecapsule
Dec 19 01:13:09 mbp15 /System/Library/CoreServices/backupd[11787]: Disk image /Volumes/timecapsule/mbp15.local_XXXXXXXXXXXX.sparsebundle mounted at: /Volumes/TimeCapsuleBackup
Dec 19 01:13:09 mbp15 /System/Library/CoreServices/backupd[11787]: Backing up to: /Volumes/TimeCapsuleBackup/Backups.backupdb
Dec 19 01:13:18 mbp15 /System/Library/CoreServices/backupd[11787]: No pre-backup thinning needed: 2.01 GB requested (including padding), 116.41 GB available
Dec 19 01:13:18 mbp15 /System/Library/CoreServices/backupd[11787]: Waiting for index to be ready (906 > 0)
Dec 19 01:14:33 mbp15 /System/Library/CoreServices/backupd[11787]: Copied 2639 files (81.1 MB) from volume mbp15.
Dec 19 01:14:34 mbp15 /System/Library/CoreServices/backupd[11787]: No pre-backup thinning needed: 1.91 GB requested (including padding), 116.41 GB available
Dec 19 01:14:52 mbp15 /System/Library/CoreServices/backupd[11787]: Copied 1654 files (160 bytes) from volume mbp15.
Dec 19 01:15:00 mbp15 /System/Library/CoreServices/backupd[11787]: Starting post-backup thinning
Dec 19 01:16:40 mbp15 /System/Library/CoreServices/backupd[11787]: Deleted backup /Volumes/TimeCapsuleBackup/Backups.backupdb/mbp15/2008-12-18-005955: 116.41 GB now available
Dec 19 01:16:40 mbp15 /System/Library/CoreServices/backupd[11787]: Post-back up thinning complete: 1 expired backups removed
Dec 19 01:16:40 mbp15 /System/Library/CoreServices/backupd[11787]: Backup completed successfully.
Dec 19 01:16:43 mbp15 /System/Library/CoreServices/backupd[11787]: Ejected Time Machine disk image.
Dec 19 01:16:59 mbp15 /System/Library/CoreServices/backupd[11787]: Ejected Time Machine network volume.
TimeMachine(backupd)が勝手にリモートボリュームとそのボリューム上にあるイメージファイルをマウントしているのが分かる。

これで数日使ってみたが特に問題なく使えている。

それはともかく、これはなかなか便利。もっと早く設定しとけばよかった。

2008-12-11

PC 復旧した

しばらく前に、うちの Windows PC が壊れたらしい話を書いた。そのときは電源が原因らしいなぁと思っていたので、いろいろ調べて Just MyShop から購入したのがこの電源。
PowerSupply
壊れてから、電源を購入してそれが届くまで約2週間。ようやく復旧できると思って、電源をさっそく交換してみた。

しかし、動かなかった、全く交換前と同じ症状。メモリチェックが走って、スクリーンに「Memory T」が出たところで止まってしまう。

ちょっとショックを受けながらも、原点に帰って Google 先生におうかがいを立ててみた。今度はマザーボードのメーカー「GIGABYTE」と 「Memory T」を検索キーワードにして。すると カカクコム の掲示板で同じ症状で困っていた人の話が見つかったのだけど、解決方法がなんと USB の外付け機器を外すというもの。まさかまさかと思いつつも、外付けディスクを外してみると……BINGO! 無事起動。

なんで USB なんだろうとか思いながら、再度繋ぎなおしてみると今度はなんの問題もなく起動する????

なんだかよく分からないけど、普及したのはまぁめでたいことなので取り敢えずはよしとしておく。その後、SPORE も若干進んでとうとう宇宙にも進出したことだし。

2008-12-07

iPhone アプリのインストール数

PhotoShare の Big Canvas の中島さんのブログ "Life is Beautifule" で、「iPhone ユーザは一年間どのくらいアプリの購入に費すのか?」というトピックがあがっていたので、有料のものだけでも数えてみた。

思ったよりも少ないけど、Appigo Todo、アスファルト4、ネオサメガメ あたりはけっこうなお値段だったので、総額で4000円くらいかな。

無料のものでも、もっとよく使うものや便利なもの、楽しいものもたくさんある。それについてもいずれまとめてみよう。