ファイルシステムが「HFS拡張（大文字小文字を区別／ジャーナリング）になっているのがトラブルの原因じゃないかというご指摘を検証〜失敗〜でもくじけへんでぇ（１）
〜今度こそTime Machineを試してみたぞ

BBSにSakiPapaさんよりこういう書き込みをいただいた。

「muta さんは HFS 拡張（大文字／小文字を区別する、ジャーナリング）で初期化されていますね。

UNIX の伝統では大文字／小文字を区別するのですが、クラシック Mac OS では（DOS 同様）大文字／小文字を区別しないという歴史がありました。OS X では（過去との整合性のためでしょうか）「大文字／小文字を区別しない」はサポート外だったと思います（少なくとも Tiger までは）。

現在でも Adobe のソフトウェアなどで、「大文字／小文字を区別する」で初期化しているディスクにはインストールできなかったり、動作しないものがあるようです。iTunes のライブラリを移行する際にも、問題が生じる可能性がありそうです。

muta さんが経験されているトラブルのいくつかについては、この「大文字／小文字を区別する」で初期化されていることが原因のようにも思えるのですが？　あくまでも想像ですよ。」

大変ややこしい話なのだが、ディスクをフォーマットする時に HFS＋とかジャーンリングとかという選択肢ともうひとつ「大文字小文字を区別する」という選択肢がある。
私の記憶では昔からそうだった気がしていたが、ちゃんと調べてみるとそれは私の記憶違いで、これまでは「大文字小文字を区別しない」でフォーマットしていて、今回のLeopardで初めて「大文字小文字を区別する」でフォーマットしたことになる。

先日の「英語環境」でいえば「Case Sensitive」ということになる。

いくつか思い当たる節があるので早速これを検証することにした。
ただしフォーマットをし直してクリアインストールをして環境を復活というのはさすがにメンドクサイ。
Leopard環境でもう１ヶ月も仕事しているので、結構それなりにドキュメントや設定が積み上がってきている。

そこでかねてからの懸案のTime Machineを使うことにした。
手順は
１）最新システムをTime Machineでバックアップ
２）内蔵ディスクを「HFS＋、大文字小文字を区別しない／ジャーナリング」で初期化
３）Time Machineでシステム全領域を復元
という手順でやることにした。

ディスクユーティリティで調べてみるとLeopardはこのように
「大文字小文字を区別」というフォーマットが見えている

ところがこの前まで使っていたTiger／PPCiBookでは
「大文字小文字を区別しない」でフォーマットしていた

先日iTunesライブラリのコピーで引っかかった項目は
iBookではちゃんと一つしか見えていない
LeopardからTigerにiTunesライブラリのコピーに失敗した原因はこれだとほぼ断定

そこで起動ボリュームを初期化して「大文字小文字を区別しない」で
フォーマットしてTime Machineでシステムを戻すことにした
手順はシステムインストールディスクから起動して起動ボリュームを初期化
メニューからTime Machineを起動して
「システムの復元」で「続ける」をクリックでシステム全域を復元できる

インストール先ボリュームを選択

あとはおよそ２時間弱ひたすら待つだけ

さてついにTime Machine初登場である。
（前回は結局復元すべきファイルがバックアップを取る前に消えていたので不発）
Time Machine使用の手順はふたつある。
１）特定のディレクトリの復元はメニューバーのTime MachineアイコンまたはTime Machineアプリ本体を起動して入る
戻りたい時間に合わせて「復元」をクリックするとその時点に表示しているディレクトリが戻る
２）システム全域を修復したい場合はシステムディスクから起動する
その上でインストーラのメニューコマンドに「Time Machine」があるのでこれを起動する
すると「復元するか」訊いてくるので以下その指示に従って進んでいく

システム全領域を復元するのにかかった時間は私の場合２時間弱というところだ。
これはiTunesライブラリの27ギガを含んでいるので、普通の人なら１時間半弱で完了するに違いない。
システムをクリーンインストールして移行アシスタントで全てのファイルを移すよりも明らかに速い。

今回はTime Machineを指導させる前にディスクユーティリティで起動ボリュームを初期化、
「HFS＋　（ジャーナリング／大文字小文字を区別しない」
設定でフォーマットした。
さてどうなるか・・・

およそ２時間後に起動ボリュームにディスクユーティリティをかけてみると
フォーマットの「大文字小文字を区別する」もちゃんと復活している
思えばTime Machineをかける時に最初に「ディスクを消去しますか」と訊いてくる
消去しないと次に進めないので「OK」をクリックしたのだが
あの時に前のフォーマットも復元してしまったらしい

その結果はキャプチャーの通りである。
Time Machineはみごとに機能した。
以前のシステムをそのまま再現してくれただけでなく、起動ボリュームのフォーマットまで
「大文字小文字を区別する」
に復元してくれた。
恐るべしTime Machine！

結果分かったことは、Time Machineはディスクのフォーマットが壊れてしまった時にも救いになる強力なバックアップソリューションとなりうるという心強い結論だ。
おかげでこの検証は失敗したのだが・・・

こんなことではくじけへんでぇ。
この検証（２）へと続く。

ファイルシステムが「HFS拡張（大文字小文字を区別／ジャーナリング）になっているのがトラブルの原因じゃないかというご指摘を検証〜失敗〜でもくじけへんでぇ（２）
〜SuperDuper!を試してみたぞ

先日の記事の通りシステムのバックアップに失敗したと言うか、成功し過ぎてせっかくファイルシステムフォーマットを変更してもそれも元に戻ってしまって、うまくいかなかった。

ここでシステムを一度別のボリュームに退避させて、フォーマットをやり直してブートできるシステムをまるまるコピーできるアプリで復元することを試した。

それにはSuperDuper!を使用した。

SuperDuper!

これはシステムをブートできる状態で別ボリュームに完全コピーできるアプリ。

コピー先のボリュームからも起動できる。
操作は非常に簡単。
コピーファイルは「全て」か「ユーザファイル」を選択できる。
ブート可能なボリュームにとしてバックアップするのは「全て」をバックアップした場合のみだ。
Sandboxはシステムのチェックポイントのみをバックアップするというもので、使い方がよくわからなないので、とりあえず割愛。

選べるのはこれだけで特定のディレクトリをバックアップから除外するような自由度はない。
しかし簡単操作でブート可能なシステムをバックアップできるメリットは大きい。

ワンパスワードでアクセス権を突破して一気にすべてをバックアップするにはシェアウエア登録をする必要があるようだ。

SuperDuper!の操作画面
コピー元とコピー先を選び「Backup-all files」で起動可能なバックアップができる

錠前アイコンをクリックして「自動認証」に入ると「シェアウエア登録しろ」とくる
登録しない場合はいちいちrootのパスワードを入力することを求められる

あとは「Copy Now」でひたすらコピーされるのを待つだけ

ところで最近パーティションマップを切っていないということをここでも書いたと思うが、そのためにiTunesライブラリを起動ボリュームに置くようになった。
それで起動ボリュームは結果的には70GB程度のでかいファイル群になり、そんなでかいファイルを一カ所に保存できるボリュームがウチにはないことに気がついた。

SuperDuper!は空き容量が不足していてもとりあえずバックアップの動作に入ってしまう。
スタートする前に
「空き容量が足りないのでこのバックアップは実行できない」
というアラートを出して停まるのがMac的なオペレーションなのだが、このSuperDuper!はそういう点ではあまりMac的ではない。

SuperDuper!は結局途中で停まってしまい、
「６００００ほどのファイルが保存できなかった」
というアラートを出した。
勿論そこからの起動には失敗したのでシステムのバックアップには失敗したということだ。
iTunesライブラリをバックアップから除外できれば、うまくいきそうなのだが、その方法がない。

結局これでフォーマットだけ変更してシステムを戻すという試みは失敗した。
失敗したが、空き容量充分のバックアップディスクがあればこれは強力なバックアップになりそうに思った。

まだまだくじけへんでぇ。
この検証は（３）に続く。

ファイルシステムが「HFS拡張（大文字小文字を区別／ジャーナリング）になっているのがトラブルの原因じゃないかというご指摘を検証〜今回はちょっとくじけたでぇ（３）
〜やっぱり外付けハードディスクで試してみるよ

BBSで私がここに書き連ねているもろもろの不具合は
「HFS＋（ジャーナリング／大文字小文字を区別する」
でディスクをフォーマットしたからではないかという指摘を「SakiPapa」さんからいただいて、思い当たる節もあったのでそれからそれを検証するために激闘を続けてきたわけだが、ここまでことごとく失敗した。

ここは基本に戻ってTime MachineやSuperDuper!を使ってシステムを移すというようなお手軽な方法をやめて、システムをきちんとイチからインストールして検証することにした。
インストール先はSuperDuper!でバックアップに失敗した外付け2.5インチディスクのmomobayにすることにした。

最初からこうしていれば貴重な連休の休みを１日棒に振ることはなかったのだ。

手順はこうだ。
１）外付けディスクを「HFS＋（ジャーナリング／大文字小文字を区別しない」でフォーマット
２）システムディスクからクリーンインストール
３）移行アシスタントで内蔵ディスクのシステムの主要部分設定、アカウント等を移行する

その上でiTunesのライブラリ移動、iCalのデータベースエクスポート等のトラブルが再現するか見てみることにした。

新規システムインストールにおよそ２時間、移行アシスタントとアップデートでおよそ１時間、３時間ほどで外付けディスクに新しい起動ボリュームを作った。
今度は抜かりなくフォーマットは、
「HFS＋（ジャーナリング／大文字小文字を区別しない」
のままだ。

さてどうなるか

まずはiTunesの方は問題なくライブラリをTigerに書き出せた。
これは予想通りだった。

予想外だったのはAdobeのPhotoshop Elements 4.0。
これはここのログには書いていなかったが、長年愛用したPhotoshop7がついにLeopardでは起動できなくなってしまったので、ライセンスが余っていたPhotoshop Elements 4.0を導入しようと考えた。
ところが、最初に一度だけインストールに成功して起動もできたが、システム再インストール後は何度トライしてもインストールに失敗、これが使えなくなっていた。

ググってみたところPhotoshop Elements 4.0はLeopard非対応となっていて、実際に使えないかどうかは結構微妙な感じ。
環境設定ファイルを捨てると起動できなくなっても復帰するという情報もあったが、インストールすらできないという状態では試しようがなかった。
ともかく使えなかったのはLeopard非対応のせいだと思っていたのだが、一応検証してみた。

Photoshop Elements 4.0のインストーラを実行
システム再インストール後は何度やってもインストールに失敗していた
「事後処理のスクリプトがみつからない サポートに問い合わせよ」というアラートが出ていた

ところが今回は何と１回であっさりインストールに成功した

ちゃんと起動して画像の読み込みもできた
Photoshop Elements 4.0はLeopard非対応で使えるかは微妙なところだが
今までインストールにも失敗してきたのはバージョンのせいではなく
ディスクフォーマットのせいだったというのがなんとなく驚き

このとおりPhotoshop Elements 4.0はLeopardでもインストールに成功してちゃんと起動もできることが分かった。
これからもステディに使えるかは微妙だが、Photoshop Elements 6を買うまではお預けだと思っていたのが使えることになりそうなのでちょっとうれしい。

そこで最近問題を起こしているiCalについても検証してみることにした。

iCalのスケジュールデータをTigerからLeopardにはバックアップ書き出しとバックアップからの修復を使って渡せるのだが、逆ができない。
これまではPanther、Tigerとも
"~/Library/Application Support/iCal"
というフォルダをそのままコピーするだけでカレンダーデータを共有できたのに、これがTiger／iBookに渡せないのが不便だと思っていた。
この新規ボリュームならどうだろう。

一番最近の変更を共有できるかテストするためにダミーのスケジュールデータを書き込んでみる
これを渡せるかが問題だ

外付けのLeopardボリュームのiCalには渡すことに成功したが
結局iBookにはカレンダーデータのコピーも実際の画面に反映せず
バックアプファイルからリバートしてみたがこれも失敗した

これもキャプチャー通り、結局外付けボリュームのLeopardには渡すことに成功。
しかしそこからiBookに渡すと
"~/Library/Application Support/iCal"
の丸コピーもバックアップファイルからの修復も失敗した。
これは今までと全く結果が変わらない。

これで何が言えるかというとこのiCalデータの引き渡しに失敗するのはこのディスクフォーマットの問題ではなくもっと違うことが原因になっているということだ。
それが何かまでは、突き止める根気がここで切れてしまった。

結局くじけたけど問題の一部は解決したわけだから、連休の休日をまる二日費やしたのも良しとするか。
あとは本体内蔵ディスクを再フォーマットしてシステムを入れ直す根性があるかどうかだけの問題になってきた。

RSSが文字化けする、ゴミ箱に入れたファイルがすぐに消えてしまう〜などに対処 〜SuperDuper!、Time Machineの信頼性に疑問

昨晩からRSS全文配信に使っているFeedBurnerが文字化けしている

表題の通りで、RSSを登録いただいている皆さんにはご迷惑をかけしているのだが、FeedBurnerの全文配信の方が日本語が文字化けしている。
見出しのみ配信の方のMyRSSの方は問題ない。
FeedBurnerは読み込みごとに化けたり戻ったりしている。偶数回はちゃんと読めて奇数回は化けている感じだ。
だから５０個のエントリが１００個に見えて、そのうち半分が全部
「???????????????MacOSX??????????????」
のような状態になっている。

一晩経ったら回復するかと思ったが、今日の昼の段階でまだ治っていない。

原因は分からない。
こちらのRSSフィードジェネレータのFeederが吐き出すテキストは、どのRSSリーダで読んでもちゃんと読めるので、テキストエンコーディングを間違えたとかではないと思う。



anchor

先日テストしかけて挫折したSuperDuper!をテストする

消えていたTime Machineバックアップボリュームをデスクトップにマウントするためにフォーマットしてしまったので、空き領域たっぷりのスペースができた。それで先日試しかけたSuperDuper!
を再びテストすることにした。

今回は空きスペースは充分だったが、結果的には挙動不審。
起動可能な状態で内蔵システムをバックアップできるというのは素直に感心するが、バックアップというには信頼感もうひとつな印象。

SuperDuper!のリマインダ
レジストしていないと毎回パスワードを要求される

今回は空きスペースが充分あったせいかちゃんと成功したという表示で終わった

起動ディスクの項目にも起動できるボリュームとしてちゃんと認識されている

ところが初回の起動はこのようなマークが出て失敗

optionキーを押しながらもう一度再起動してみると
SuperDuper!でバックアップを作ったボリュームが二つ見えている
これが起動失敗の理由らしい

これらの症状はディスクの診断、アクセス権の修復等一通り試したが治らない

さらにSpotlightもメタデータ生成に４０分というような表示を出しているのに延々数時間回り続けている
確かにブータブルなバックアップは作れたが信頼性としてはどうだろう

ゴミ箱に入れたファイルがすぐに消えてしまう〜Time Machineの信頼性にも疑問が・・・

ゴミ箱に入れたファイルが削除できないというような問題にはこれまで何度も遭遇してきたし、その対処法もいろいろ有る。
ところが今回は、ゴミ箱に入れたファイルが即座に削除されてしまうために一時的に何かをゴミ箱に退避させることができないというトラブルだ。

発端は以下の通り。

上記のようにSuperDuper!に見切りをつけたのは、その信頼性がいまいちな感じがしたからというのもあるがもっと重要だったのが 移行アシスタントは外付けの起動可能なボリュームからは移行できないということを発見してしまったからだ。
さらに移行アシスタントはTime Machineからは移行できるらしい。
だったら無理してTime Machineのボリュームを消すこともなかったんじゃないか？

それはともかくそれでSuperDuper!で作ったボリュームを再び初期化してTime Machineでバックアップを取った。

移行アシスタントは別のMacからユーザファイルを移行できるが
それは移行アシスタントを起動したMacかディスクターゲットモードで起動したMacに限る
外付けのバックアップからはたとえブータブルだろうが移行できないらしい
ところがここで「Time Machineから移行」という項目も見つけてしまった
外付けのTime Machineボリュームからは移行できるらしい

ということでおよそ２時間システム全域をTime Machineでバックアップ
さらにMacBookを初期化、クリアインストールして移行アシスタントを使って
新品のシステムにTime Machineから環境を移行した
これで例の「大文字小文字を区別する」フォーマットを変更して
アカウント情報はほぼ前のままで使えるようになった

これでディスクのフォーマットの変更、システムの更新をクリアインストールで行って、しかも半日で前の環境を大部分引き継いで同じように使えるようになった。
引き継いでいないのはモバイル設定、Bluetoothモデム設定、プリンタ設定くらいのものでしかもプリンタ設定は必要なネットワークにつなぎさえすれば簡単に復元されてしまうので、本当に昔と比べたらシステムインストールが楽になった。

ところがここで問題が起こった。
ゴミ箱に何かを入れるといきなり
「すぐに削除されます　削除してもいいか？」
というアラートが出て削除するかゴミ箱に移動しないか選択しなくてはいけなくなる。
つまりゴミ箱に一時的に何かを退避させるということができなくなっているということだ。

ゴミ箱に移動できないとか、ゴミ箱を空にできないというトラブルは割とよく見かけるのだがゴミ箱がすぐ空になってしまうというトラブルは初めて見た。

それでググってみるとこの症状はゴミ箱の本体である
.Trash
というフォルダーが消失している時に起きる症状だという情報を見かけた。

これがヒントになった。

新しいシステムで起こったいきなりの挙動不審
ゴミ箱がこういうアラートを出してすぐにファイルを削除しようとする
このために一時的にゴミ箱にファイルを退避させることができない

ゴミ箱のアクセス権が壊れている可能性があるとのことなので
ls -ld ~/.Trash
というコマンドをTerminalに打ってみる
アクセス権については特に異常は無さそうだ

ところがFinderの移動メニューから「~/.Trash」に移動して見ると
「フォルダがみつかりません」とくる

異常があることは間違いなくてFinderの「ゴミ箱を空にする」コマンド等が
グレーアウトしていて何度再起動してもこの状態から脱出できない

そこでMainMenuを使って不可視ファイルを見えるようにしてみると
なんとそのゴミ箱の実体の.Trashがフォルダであるべきなのにテキストファイルになっている
どおりでアクセス権の修復だけでは復帰できなかったわけだ

この「ファイル」を削除して再度ログインし直すとちゃんと正常なフォルダに戻った

以降ゴミ箱の振る舞いは正常になりFinderの「ゴミ箱を空にする」コマンドもグレーアウトしていない
ゴミ箱に一時的にものを置くこともできるようになった
（註：Freeze Removerがゴミ箱に有るのはあくまでテストのためです
Freeze Removerすごいお世話になっています、実際）

このゴミ箱の実体がファイルになっていた理由はよくわからない
しかしどうもTime Machineが怪しいのではないかと見ている。

先日のRSSの文字化けもrss.xmlを直接フィードとして配信しているURLでは全く異常が起きていない。
もしテキストエンコーディングがおかしくなったのであれば、今度は１００％文字化けしていないとおかしい筈だ。
ところがFeedBurnerは奇数回の読み込みには成功して、偶数回の読み込みには失敗しているような感じだった。
GoogleReaderなどのログの時系列をさらに細かく見ていると、因果的には前回のTime Machineでシステム全領域を復元した時から調子がおかしくなっていたことが分かった。

RSS文字化けの原因はTime MachineのおかげでRSS.xmlのファイルが壊れてしまったか、Feederの設定ファイルが壊れてしまったのかもしれない。
RSSの元ファイルのRSS.xmlとFeederの設定ファイルを削除してRSSをイチから作り直したら文字化けは治った。

どうも意外にもこのTime Machineは絶対安全確実というようなものではないようだ。
というより個人的な教訓にするなら
「Time Machineの全領域修復は最後の最後の手段にせよ」
ということになるか。

他にもまだどんな不具合が有るか分からないが、一応今のところこれでほとんどの問題には対処できた。

特定のアプリケーションから脱出できない、強制終了してもすぐに勝手に起動してしまうトラブル

昨日発生したトラブル。

いくつかアプリケーションを一気に起動するとそのうちの一つのアプリケーションから脱出できなくなる。
昨日はGyazmailだったが、Gyazmailから他のアプリに移ろうとしてもすぐにGyazmailに戻ってしまう。
Finderも選択不可能になってしまう。

そこでGyazmailを強制終了すると一瞬だけ他のアプリを選択できるが、すぐにGyazmailが勝手に起動してしまい、またそこから抜けられなくなる。
これを永遠に繰り返す。

昨日はGyazmailだったが、前回にこれが起きた時にはアドレスブック、あるいはiCalだった。
だから特定のアプリの不具合ではない。

結局ここから抜け出るにはシステムの強制再起動以外にないのだが、システムを落とさずに脱出する方法を昨日は探ってみた。

アクティビティモニタを起動して一つずつプロセスを強制終了させることで検証。（その間もGyazmailが毎回起動してきていちいちそれを終了させながらの、文字通り格闘戦のようなトラシューが続く）
その結果WindowServerを終了させることで、ログイン画面まで戻れることが分かった。

WindowServerがこの問題の原因になっているかどうかまでは確認できなかった。
可能性はあるが、というより他のめぼしい怪しいプロセスは全て終了させたので多分そうだという気はするが何ともいえない。
でも原因がどうかはともかく、ログアウトまでは可能だということが分かっただけでも収穫。
一度この状況に陥ってしまうと、ログアウトの操作もGyazmailがキャンセルしてしまうからだ。

それにしてもまだ使い始めて２ヶ月目のLeopardでこういうトラブルが３度も起こっている。
こんなのはTiger以下では経験したことがないトラブルだ。
どういうんだろ？

特定のアプリから脱出できない、強制終了してもすぐに勝手に起動してしまうという場合は
この「WindowServer」というプロセスを強制終了する
これでとりあえずログアウトには成功する

Leopardのことえり（IM）に再び「はたけ」バグ！？

今日気がついたのだがLeopard／intelMac MacBookのことえりで
「わかお」
と打って変換のスペースキーを叩くとことえりが１００％の再現率でスタックすることが判明。
これはFirefoxでもiTextExpressでもSmultronでも再現したので、個別のアプリの問題ではなくことえりの問題だと思う。

確か前回のバージョンアップの前まではこのキーの組み合わせは普通に打てていたので、今のバージョン固有の問題だと思う。おそらく当然ながらTigerでは出ない問題だと思われる。

Leopardは確か最初の頃は「はたけバグ」というのがあったと思うが、あれの再来かもしれない。
そういえばJaguarはスリープを解除できなくなって結局構成再起動するというバグが最初あって、バージョンアップで解決されたような話だったが、結局どこかのバージョンで復活したりということがあったが、これも「はたけ」の再来じゃないだろうか？

皆さんのところでは問題はないのか情報を求む。

（続報）『Leopardのことえり（IM）に再び「はたけ」バグ！？』解決編〜ディクショナリ関連を総取っ替えで解決

一時期は「はたけ」バグの再来かと疑ったことえりの「わかお」クラッシュだが、原因と対処法がわかった。

＜原因＞

先日オンラインウエアのDictionary Cleanerというアプリを試そうと辞書環境設定から
LearningDictionary.dict
という辞書を有効にして登録をしようとした。
キャプチャーのように私の環境ではなぜか「LearningDictionary.dict」と「ユーザ辞書」が同居しておりこれが正常な状態なのかどうかもよくわからないのだが、変換候補の登録は「ユーザ辞書」の方でこれまでもやってきている。
「LearningDictionary.dict」はなぜか設定で「開く」にできないからだ。
（おそらく移行アシスタントを使ってTigerの環境を引き継いでいる関係かと思われるが、Leopardのデフォの環境が分からないので断言できない）

今回このDictionary Cleanerが辞書の履歴を編集できるということなのでそれができれば便利だなと思って試してみたのだが、これは「LearningDictionary.dict」に対してのみ有効な様子。
そこで「LearningDictionary.dict」を開いて単語を登録しようとした。
その最初の候補が顔文字の共通の「読み」として私が設定している
「かお」
という単語。
ところがこれを入力した時点でことえり環境設定はスタック、「LearningDictionary.dict」は何も反応しないで操作不能になってしまったので、「LearningDictionary.dict」もDictionary Cleanerも使うのを諦めていた。

ところがこれ以来「かお」という文字列を含む入力をすると全て「ことえり」がスタックするということになってしまった。
「わかお」もそのひとつということだった。

＜解決策＞

「LearningDictionary.dict」を開いて問題の有る部分を直す方法を模索してみたが、道は開けなかった。
それでTimeMachineの２週間ほど前のディレクトリに入っていって
"~/Library/Dictionaries"
の中身全てと
"~/Library/Preferences/com.apple.JapaneseAnalysis"
"~/Library/Preferences/com.apple.Kotoeri.plist"
"~/Library/Preferences/com.apple.KotoeriPreferences.plist"
"~/Library/Preferences/com.apple.KotoeriWordRegister.plist"
を取り出してきてMacBookの同じ場所に置き換えて再起動した。
この最終手段を講じると問題はあっさり解決した。

かおかおかお、顔、(　｀д´) 凸、わかお、若緒、若尾
このとおり好きなだけ「かお」が打てるようになった。

私の環境では「LearningDictionary.dict」と「ユーザ辞書」
が同居しているがこれが正常かどうかもわからない
ただ「LearningDictionary.dict」が「開く」にならないのでなんとなく正常っぽくない

Dictionary Cleanerを試すために「LearningDictionary.dict」
に「かお」という読みの単語を登録しようとした
問題はここから起こった

対処法は結局私がいつもアックアップを取っている辞書関連ファイルの総替えということに
今回はTimeMachineの２週間前のディレクトリから
"~/Library/Dictionaries"の辞書ファイルを全て復元した
同じく"~/Library/Preferences/com.apple.JapaneseAnalysis"
"~/Library/Preferences/com.apple.Kotoeri.plist"
"~/Library/Preferences/com.apple.KotoeriPreferences.plist"
"~/Library/Preferences/com.apple.KotoeriWordRegister.plist" を復元した

この通り好きなだけ「かお」も「わかお」も打てるようになった

＜追記＞

E-WAさん、TANBさん、もいかいさん、teraさん、その他メールなどで情報をいただいた皆さん、ありがとうございました。