Mac mini鯖に繋いでるデータ置き用HDDがぶっ壊れた。ディスクユーティリティで修復を試みるも「Bツリーが壊れてて直せない」的なエラーで修復不能だった。

「それでもTimeMachineなら・・・TimeMachineなら何とかしてくれる・・・!!」と思ってバックアップを除いてみたら、最新のバックアップは2009年7月2日とか言ってるの。え？何それ？バカなの？死ぬの？

fsckを直接叩いてみると、BAD SUPER BLOCK: MAGIC NUMBER WRONGだとかLOOK FOR ALTERNATE SUPERBLOCKS? [yn]とか言われ、代替ブロックを探すも見つからず、newfsを使った方法でもダメで、もはやお手上げ状態。

壊れたHDDにはそれほど重要なデータは入ってないから、もし本当にデータが飛んだとしてもそんなに痛くはない（夜のお供（自重汁）が減る程度で済むwある意味一大事ではある）が、諦めるのも何なのでDiskWarrior 4をポチった。

結果、いとも簡単に修復完了。1分も掛かってないんじゃなかろうか。

そんなわけでDiskWarriorは神。それに引き換えDrive Geniusは………買ってはみたものの、どうすんのよこれ………。

MacPortsでSubversion 1.6を入れただけでは、Xcodeから上手く使えない（システム標準の1.4が使われてしまう模様）ので、使えるようにするメモ。

…と言っても、単にコマンドとライブラリを置き換えてるだけ。

MacPortsから入れる。variantsは適当に。

sudo install subversion +bash_completion+mod_dav_svn+tools+unicode_path

cd /usr/bin
 
#一応前のコマンドを退避
sudo mkdir svn_old 
sudo mv svn* svn_old
sudo mv apr-1-config svn_old
sudo mv apu-1-config svn_old
 
sudo ln -s /opt/local/bin/svn* .
sudo ln -s /opt/local/bin/apr-1-config .
sudo ln -s /opt/local/bin/apu-1-config .

元からあるシンボリックリンクは、可能な限りそのまま活用する方針で。

cd /usr/lib
sudo mkdir svn_old
sudo find . -regex ".*libsvn_.*-.*1\.0\.0\.0\..*" -exec mv {} svn_old \;
sudo mv libapr-1.0.2.7.dylib svn_old
sudo mv libaprutil-1.0.x.x.dylib svn_old # バージョン番号を失念してしまったので、適当に補完して下さい。
 
sudo find . -regex ".*libsvn_.*-.*1\.0\.0\.0\..*" -exec rm {} \;
sudo rm libapr*
 
sudo find /opt/local/lib -regex ".*libsvn_.*-.*1\.0\.0\.0\..*" -exec ln -s {} . \;
sudo ln -s /opt/local/lib/libapr-1.0.3.5.dylib .
sudo ln -s libapr-1.0.3.5.dylib libapr-1.dylib
sudo ln -s libapr-1.0.3.5.dylib libapr-1.0.dylib
sudo ln -s /opt/local/lib/libaprutil-1.0.3.7.dylib .
sudo ln -s libaprutil-1.0.3.7.dylib libaprutil-1.dylib
sudo ln -s libaprutil-1.0.3.7.dylib libaprutil-1.0.dylib

swingとかperl用のモジュールが足りてないような気がするけど、うちでは関係なさそうなので気にしてない。無いと困るって人は、上手い事対処して下さい。

SubversionのサーバとしてMac OS Xを使用し、svn+sshでアクセスする場合はサーバ側でも同様の置換を行う。

昨日、遂に開始＆発売されたauのデータ通信定額＆専用端末のW05K。ヨドバシ八王子に行ってみたら、auの音声端末を持っている人は新規1円だったので契約しました。

うちにはWindows搭載のノートPCは無かったりしますが（MacBook ProにXPは入れてますが肝心のCFスロットが無い）、非公式ながらZaurusでの動作報告を耳にしていたので、うちのSL-C3200でも動くだろうと期待して帰宅。そして早速設定＆接続。

今まで使っていたbitWarp PDAと比べて、明らかに体感速度が違います。画像なんかもスルスルと表示されます。

ベンチを取ってみると、720kbpsを叩き出しました!!ww これで遅い訳がないww

それからリナザウをルータ化し、Macからニコニコを見てみましたが、普通に見れて感動。その時の回線状態やパケット制限（？）の影響で、同じ動画でも途中で途切れたり、途切れなかったりします。しかし途中でバッファリングが入っても、せいぜい1,2秒で直ぐに再生が再開されるので、個人的には十分に“使える”と思いました。

さらば、bitWarp。

全国のDVD-RAM原理主義者でMac使いのみなさーん、朗報でありますよー。Leopardから、遂に……遂にUDFでフォーマットされたDVD-RAMへの書き込みが可能になりました!!これで、わざわざFAT32やらHFS+というDVD-RAM界では邪道（？）のフォーマットをする必要も、Samba共有でWindowsからUDFなRAMへ書き込む必要もなくなります!!

WikipediaのUDFの項によれば、Mac OS X v10.5からUDF 1.5は元より、UDF 2系列の書き込みに対応した模様です。実際HL-DT-ST GSA-4082BをUSB変換器で接続して試してみたところ、見事UDF 1.5なDVD-RAMに書き込みが出来ました。うーん、素晴らしいっ!

ただ、うちで試した限りでは以下の制約がありました。

• UDF以外でフォーマットされたメディア（ブランクも含む）はUDFでフォーマット出来ない（形式一覧にUDFが出てこない）
• UDFでフォーマットしようとすると、途中で止まる。

要は、UDFで初期化できません……。なので、UDFで使いたい方は予めUDFフォーマット済みのメディアを購入するか、ブランクメディアやUDF以外のメディアは、一度Windows等でUDFでフォーマットし直す必要があります。Macオンリーの方はちょっと不安かもしれませんね。UDFなメディアを別の形式で初期化し直すのは問題ないようです。

まぁ初期化に問題があるとは言え、UDFで読み書き出来るようになったのは非常にありがたいです。これからは、MacでもガンガンDVD-RAMが使えます。ひゃっほーい。

UDFでのフォーマットに関して、うちでは出来たよ!等々の情報がありましたら、是非お教え下さい<m(_ _)m>

（2007/11/28 追記）
1GBちょっとのファイルを書き込んでいたら、突如マウント解除→書き込み失敗→既に書き込んであったファイルも消失という事態が発生してしまいましたorz 消えたファイルはTime Machieのバックアップのお陰で復元できましたが、UDF（と自前外付けドライブ？）での運用はちょっと気をつけた方がいいかもしれません。

Xcodeをlipoで調べると、x86系、PowerPC系共に32bitと64bitに対応している（バイナリを持っている）事がわかります。ですが、普通に起動すると、32bitバイナリの方が起動してしまいます。

fat_magic 0xcafebabe
nfat_arch 4
architecture ppc7400
    cputype CPU_TYPE_POWERPC
    cpusubtype CPU_SUBTYPE_POWERPC_7400
    offset 4096
    size 132272
    align 2^12 (4096)
architecture ppc64
    cputype CPU_TYPE_POWERPC64
    cpusubtype CPU_SUBTYPE_POWERPC_ALL
    offset 139264
    size 198896
    align 2^12 (4096)
architecture i386
    cputype CPU_TYPE_I386
    cpusubtype CPU_SUBTYPE_I386_ALL
    offset 339968
    size 128000
    align 2^12 (4096)
architecture x86_64
    cputype CPU_TYPE_X86_64
    cpusubtype CPU_SUBTYPE_X86_64_ALL
    offset 471040
    size 170080
    align 2^12 (4096)

ところが、Xcode.app/Contents/MacOS/Xcodeを直接実行すると、しっかりと64bit版が起動します。

「なんでかなー？」と悩む事30分。Finderの「情報を見る」に「32 ビットモードで開く」というチェックがあるのを発見しました。このチェックが入っていると、64bitなバイナリが含まれていても、優先して32bitなバイナリを実行するようになるみたいです。

更に調べてみたところ、Info.plistのLSArchitecturePriorityキーで使用するアーキテクチャの優先度を指定できるようです。

Leopardで追加されたこのキーはString型の配列で、現時点で i386/x86_64/ppc/ppc64 の値を入れる事が出来ます。基本的には配列の先頭に近いアーキテクチャほど、実行の優先度が高くなります。

しかし、最も優先されるのは先のFinderによる設定のようです。LSArchitecturePriorityがi386/x86_64の順になっていても、「32 ビットモードで開く」にチェックが付いていなければ、x86_64のバイナリで起動します。

Appleの資料によれば、ppcをi386よりも前に書けば、Intel Mac下における強制Rosetta実行も可能らしいです。ただし、LSRequiresNativeExecutionキーがYesだと、Rosetta環境では実行されなくなるみたいです。

色々と実験してみたのですが、Info.plistを書き換えてると、その内書き換えた内容が反映されなくなる？ようで、これらのキーの挙動の全容がいまいち掴めていません。まぁ、普通のアプリを作る上では、特に弄る必要はなさそうですけど。