Time Machine がなかなかバックアップを始めない
昨日から Time Machine からの復元をさせていたが、朝 7 時頃には復元が終了して再起動が始まった。早速ディスクユーティリティを起動してみたところ、やはりリカバリ領域は作られていなかった。当たり前のこと。
せっかくディスクユーティリティを起動したので、念のためディスクを検証しておく。エラーがなかったのでほっとする。
Time Machine の環境設定を見ると、バックアップの準備中になっていたのでしばらく放っておいた。放っておいたのはいいのだが、13 時になっても終わらない。その後しばらくしたら古いバックアップのクリーンアップ中というメッセージに変わったが、これもなかなか終わらず。ようやく 19 時頃になってバックアップが始まった。どうもフルバックアップを始めているようだ。また 9 時間くらいかかるのだろうか。
今のところ Time Capsule とは有線でつないでいるけれど、これが無線だったら何日かかるんだろう。
Humphrey (MacBook Pro 15") の HDD を換装する
昼間所用をすませて帰宅。Susan は無事復元できていた。Susan でネットをブラウズしていると、Amazon から荷物が届いた。
早速内蔵 HDD を取り外そうとしたらプラスドライバがなかなか見つからず難儀したが、換装自体は簡単に終了。
Mountain Lion のリカバリディスクを作っていなかったので、Snow Leopard の DVD から起動して Time Machine で復元しようとしたら、途中でエラーになって復元できず。Snow Leopard からは Mountain Lion のバックアップは復元できないのか? 仕方がないので一旦 Snow Leopard をインストールして Mountain Lion のインストーラを再ダウンロードすることにした。後から考えると、換装する前のディスクを外付けケースに入れて、リカバリ領域から起動すればよかったのかもしれない。しかしディスクはクラッシュしているのでケースを購入するなんて考えには至らなかった。
30 分かけてインストールしたものの、AppStore はついていなかったので、ソフトウェアアップデートをかける。これに 20 分くらいかかった。そして Mountain Lion のインストーラを 1 時間かけてダウンロード。すぐにでもインストールしたかったが、ちょうど使っていない USB メモリがあったので、今度はインストールする前にリカバリ用のインストールディスクを作った。
そしてインストールして Time Machine で復元と思ったが、ここまででもう 22 時を回ってしまっていたので面倒になり、インストールしないで Time Machine からインストールできるかどうか試してみた。するとどうやら順調に復元している様子。ただ考えてみると、リカバリ領域は作られないのだろうな。まあ、USB メモリにリカバリディスクを作ったからいいか。
ハードディスクを探す
ハードディスクのことを職場の同僚に相談したら、内蔵 HDD なら Amazon で購入したという。それも一万円以下で。安くなったもんだなあ。
でもとりあえず土曜日中に換装をすませたかったので、明日朝一で近所の家電量販店に行ってみることにして、Susan にもディスクユーティリティで検証をかけてみた。するとディレクトリの数が一致しないというエラー。これも修復できない。
こういうことって、まとまって起こるものだなあ。
ネットに接続できないと、家電量販店に HDD がなかった場合、HDD を買う手段がなくなってしまう。しかし、リカバリ領域から起動される OS X ユーティリティには「ヘルプ情報をオンラインで取得」という項目がある。ここから Apple のサイトにアクセスできるのだ。そこで Amazon にもアクセスできないかとやってみたところ、ちゃんとアクセスできて、サインインもできた。
内蔵 2.5" HDD を検索したところ、Hitachi の 750GB 7200RPM が 6千円台だった。明日近所の家電量販店に行って売ってなかったらこれを買うことにしよう。
Humphrey (MacBook Pro 15") のハードディスクがクラッシュした
先週の土曜日に、 OS X を Mountain Lion にアップグレードした。 何日か普通に使えていたのだが、 Safari を使っていたら急にマウスカーソルがクルクルになってしまって止まらなくなった。 気が急いていたせいか、 思わず電源ボタンを長押しして強制終了したのだが、 これがいけなかった。 しばらく使っているとマウスカーソルがクルクル。 2、3 分くらいで復活。 またクルクルの繰り返しになってしまった。 そして何回か、 強制終了を繰り返していたら、 とうとうハードディスクのリカバリ領域から起動してしまった。
そこで、 ディスクユーティリティを使ってディスクの検証をしてみたところ、 もちろんエラー。 そして修復でもエラーになる。 仕方がない。 こんな時のための Time Capsule ですよ。
しかし、 Time Machine からの復元中にマシンがリセットされて、 またリカバリ領域から起動する。 これってもしかしてすごくヤバい状態? いわゆるディスククラッシュというやつですか。 もうディスクを換装するしかないのか。 近所の家電量販店の PC 売り場で内蔵 HDD は売っているのか。 なぜかテンション上がる。
ネットで情報を調べようと、 久々に Susan (PowerBook G4 12") を起動する。 しかしなぜか、 インターネットにつながらない。 ネットワークユーティリティを起動すると、 どういうわけか自己割り当て IP になってしまい、 DHCP から IP を取得できない。 なんなんだろうか。
64ビットLinuxを再インストールして、誰かさんのプログラムをデバッグする
今日は Red Hat Enterprise Linux 6.1 x86_64 を再インストールした。
インストールする時に、基本サーバを選択して開発ツールソフトウェアを追加しておいた。開発ツールに気を取られてネットワークの設定をするのを忘れてしまった。まあこれは network-scripts/ を編集すればいいだけだ。
さて、自前のプログラム、といっても前任者が作ったものだが、をリコンパイルした。するとワーニングが山ほど出てくる。といってもほとんど全部が strcpy とか localtime の宣言がないというワーニングだ。こんなのヘッダファイルをインクルードすれば消える話なのに、なぜに放っておくんだろうか。たいした問題にはならないワーニングだけれども、他の重要なワーニングを見落とす可能性があるのに。なので、とりあえずヘッダファイルのインクルード指令を追加しておいた。
ということで実行してみると、指定されたディレクトリがないというエラーになる。しかしそのディレクトリは確かにある。ソースコードを眺めてみると、ログファイルを出力する仕掛けが埋め込まれていたので、それを有効にして実行してみた。
すると iconv 関数の戻り値が -1 になっているのでエラーで終わっている模様。しかし指定したディレクトリ名は ASCII コードの文字列なのになぜ。と思って iconv を呼び出しているところを見ると、size_t 型の変数へのポインタを引数として渡すところに、int 型の変数のアドレスを size_t * でキャストして渡している。strcpy のワーニングは放っておくのに、ここはちゃんとワーニングをつぶしたのか、偉い偉い。
というか、64ビット Linux では int は 4 バイト、size_t は 8 バイトだから、バッファーオーバーランが起こってるよこれ。よく暴走せずに動いたもんだなとよく見ると、その引数の int 型の変数の次の行で、使われていないchar型の配列が定義されている。ああ、これのおかげか。
しかし、型の違いを対症療法的にキャストで誤摩化そうとするのはどういう心理状況なんだろう。素直に変数を size_t で定義すればいいだけなのに。
というわけで、変数を size_t にしてリコンパイルしたら、無事動くようになりました。
