Lionへアップグレード後のHDD換装
20 日にウチの MacBook の OS X を Lion へアップグレードしたのですが、その際ついでに XCode を App Store からインストールしようとしたところ、HDD 容量不足で入れられませんでした。HDD 容量は残り 9G ぐらいしかありません。
これはいかん!
ということで、HDD を換装することにしました。モデルは MacBook 13-inch, Aluminum、Late 2008 。これをキーワードにぐぐると換装方法についてはたくさんひっかかるので省略しますが、最終的に 160G の HDD を 500G のものへ交換し、ついでにメモリも 2G から 4G へ増量したので、とても快適になりました。
さて、残る問題は元の HDD の内容を新しい HDD へどうやってコピーするかなのですが、私は Time Capsule 経由でデータを復元するつもりでしたので、事前に Time Capsule へデータをバックアップしてあります。
しかし、復元はなかなかうまくいかず時間もかなりかかったのですが、最終的に成功した手順は以下のような感じです。
- Snow Leopard のディスクを挿入し、電源を入れて DVD から起動する
- DVD から起動するためには電源を入れた後しばらく "C" キーを押しっぱなしにする必要がある
- ディスクユーティリティを起動し、HDDにパーティションを作成する
- 作成したパーティションへ Snow Leopard をインストールする
- この際、データの移行は後で「移行アシスタント」使うつもりなのでとりあえず何もしない
- Snow Leopard をソフトウェア・アップデートする
- このソフトウェア・アップデートでApp Storeがインストールされる
- App Store から Lion を再インストール (料金は不要)
- Lion 上で「移行アシスタント」を利用して Time Capsule からデータを復元
これで、複数のアカウントを以前と同じ状態へ復元できました。
おそらく事前に Lion の起動ディスクを作成しておけば、苦労もなく簡単に復元できたのだと思います。しまったなぁ。
失敗した手順は以下のような感じです。Time Capsule からの復元に何時間もかかるので、失敗は結構痛いです。
⇒ 復元後に再起動すると、OS X のブート中にエラーが表示されて、停止する
- 上述の状態の HDD へ Snow Leopard を上書きインストール (ここまでは成功)
- ただし、Dock 内のアイコンがいくつか表示されていない (iTunes のアイコンなど、最近更新されたもの)
- その後 App Store 経由で Lion へアップグレード
⇒ 再起動後、青い画面のまま先へ進まない
はてなブックマーク / みたくないリンク (Google Chrome 拡張版) ver 0.2
はてなブックマーク/見たくないリンク - Chrome Web Store
従来は、見たくないリンクを小さく薄く表示するようにしていたのですが、いっそのこと消してしまえ!ということで、見えなくなるようにしました。
オプションで、従来どおり小さく薄く表示することもできます。
はてなブックマーク / みたくないリンク (Google Chrome 拡張版)
はてなブックマーク/見たくないリンク - Chrome Web Store
以前 hatena_bookmark_ignores.user.js - GANAwareはてな版 というものを Firefox 用に作成したのですが、最近は主に Google Chrome を使用しているので、Google Chrome 拡張として作り直しました。
Google Chrome 拡張を作ったのは初めてですが、結構簡単に作れちゃいますね。めんどくさいのは、アイコン画像が必ず必要であることぐらいです。
vc-svn.el で --use-merge-history を使う
Emacs で vc.el (vc-svn.el) を利用して Subversion を利用する際に、デフォルトではマージ情報を表示してくれないので少々改造してみました。以下のコマンドに効果があります。
- vc-print-log (C-x v l)
- vc-annotate (C-x v g)
(defadvice vc-svn-command (before vc-svn-command--use-merge-history first (buffer okstatus file-or-list &rest flags)) "vc-svn-command with --use-merge-history" (if (and (consp flags) (stringp (car flags)) (member (car flags) '("log" "blame" "annotate"))) (setq flags (cons "-g" flags)))) (defvar vc-svn-annotate-re--use-merge-history "G?[ \t]*\\([0-9]+\\)[ \t]+[^\t ]+ " "vc-svn-annotate-re with --use-merge-history") (defadvice vc-svn-annotate-time (around vc-svn-annotate-time--use-merge-history) "vc-svn-annotate-time with --use-merge-history" (let ((vc-svn-annotate-re vc-svn-annotate-re--use-merge-history)) ad-do-it)) (defadvice vc-svn-annotate-extract-revision-at-line (around vc-svn-annotate-extract-revision-at-line--use-merge-history) "vc-svn-annotate-extract-revision-at-line with --use-merge-history" (let ((vc-svn-annotate-re vc-svn-annotate-re--use-merge-history)) ad-do-it))
CP932 → UNICODE → CP932 : PHP 5.3.3 も調べてみた
「php も調べてみた - GANAwareはてな版」で PHP 5.3.0 について調査しましたが、その後 PHP 5.3.3 で変更がありました。
U+00A5 と U+203E の変換先が Win32 のものと一致するようになりました。
# http://www.php.net/ChangeLog-5.php#5.3.3 で言及されていないのがやや気になります。
NFD → NFC
「OSXでUSBメモリ上のNFDファイル名のファイルへアクセス不能 - GANAwareはてな版」という問題をなんとかするために、ディレクトリを再帰的に辿り NFD なファイルを発見するプログラムを C# で書いてみました。
Usage: nfd2c [OPTIONS]... DIRECTORIES...:
- -R : ディレクトリを再帰的に辿る
- -r : NFD なファイル名を発見したら NFC へリネームする
- -d DEST_DIR : NFD なファイル名を持つファイルを見つけたら、DEST_DIR へ NFC 名でコピーする
例:
C:\> nfd2c.exe -R -d D:\copied\ .
OSXでUSBメモリ上のNFDファイル名のファイルへアクセス不能
はじめに
USB メモリ (FAT32) 上に Windows 上で作成した Unicode の NFD のファイル名を持つファイルは、OSX からはアクセスできません*1。以下では現象の説明と原因の推測を行います。
発端
Windows 用の iTunes は、少なくとも v7.0.2 のころは My Music\iTunes\iTunes Music\ 以下のファイルのファイル名を NFD で保存するようになっていたようです。
つまり、
ダ.m4a
というファイルが存在する場合、そのファイル名の Unicode は
U+30bf(タ) U+3099(゛) U+002e(.) U+006d(m) U+0034(4) U+0061(a)
となります。
このファイルを Explorer で名前変更しようとすると、「ダ」のところでカーソルが 2 つ動きますし、「ダ」の後ろで Back Space を押すと「タ」へ文字が変わるという挙動を見せます。
このファイルを FAT32 でフォーマットされた USB メモリへコピーし、OSX で開こうとしたところ、 Finder や ls でファイル名をリストアップすることはできるものの、ファイルを読み取ることはできませんでした。ファイルサイズすら不明です。
逆に OSX → Windows では?
OSX 側で「ダ.m4a」というファイルを USB メモリ (FAT32) 上に作成し、Windows で開く場合は問題なく動作します。ファイル名は、
U+30c0(ダ) U+002e(.) U+006d(m) U+0034(4) U+0061(a)
であり、NFC となっています。
推測
以下は推測ですが、OSX では FAT32 へアクセスするときにファイル名を変更するんだと思います*2。
ここでポイントとなるのは、元々ファイル名が NFD で保存されている場合は readdir() 時の NFC → NFD 変換の影響をうけず、あいかわらず NFD のままだということです。
それなのに、open() するときに NFD → NFC 変換が行われるせいで、そんなファイルは見つからないということになります。
まとめ
OSX とファイルを交換する場合、FAT32 上で NFD なファイル名をもつファイルを作成してはいけません。また、OSX がファイル名を NFD で取り扱うという性質上この問題は将来的にも解決される見込みはないと思われます。
Windows 上で NFD で作成したファイルをどうしても FAT32 経由で OSX へコピーする必要がある場合、以下のような作業が必要になります。
*1:調査は Windows XP と Snow Leopard で行いました