度々書いている通り、Appleの品質に取り憑かれている．
だが．
メインマシンMBP2023を購入したきっかけはMBP2021のファイルシステムエラーが出たからだ．ちょうだ３ヶ月ほど前のことだ．
DriveGeniusで日々ディスクのリスクを監視してもらっているが、ここのところエラーが出ていた．
FirstAidでもWarningのみで、「問題なし」と報告してくる．
けれども僕は知っている．全然問題なしどころかディスクの内容を全て失う可能性とMacが超不安定になるWarnであることを．
そのWarnとは、
「snapshot fsroot / file key rolling / doc-id tree corruptions are not repaired; they'll go away once the snapshot is deleted.」
だ．
FirstAidの処理内容を見るにTIme machineのローカルスナップでエラーが出ているように見える．
--
** Checking snapshot 2 of 20 (com.apple.TimeMachine.2023-09-07-100533.local)
warning: inode (id 40715032): Resource Fork xattr is missing for compressed file.
--．
この例だと20履歴があるのでこれをバッサリ消してみる．
消した後再度FirstAidを実行しても、
「snapshot fsroot / file key rolling / doc-id tree corruptions are not repaired; they'll go away once the snapshot is deleted.」
は消えない．
fsrootが壊れているのでdiskutilを駆使しようとfsck_apfsを実行しようと解決することはない．
解決方法はフォーマットからのリストアしかなく、フォーマットしないリストアだと、あるいはリストアに失敗して「バックアップが壊れているのか・・・」と勘違い落胆を招く可能性すらある．
apfsというファイルシステムは欠陥コードなのではないかと思ったりする．海外では「バグだらけ」と酷評されているようだし、個人が使うレベルで特に強制終了など過酷な使われ方でもない、事務作業程度で壊れるファイルシステムってのはユーザに強制するようなものじゃないだろう、などと思う．HFS＋でいいんだよ．
あえてクソと呼ぶがこのクソな仕様のせいでMacのサードパーティ含むディスク修復ユーティリティが発展しない．なんちゃって修復しかできないFirstAidしかないというのは健全ではない．
fsckを名乗るfsck_apfsにおいては、全く非力な整合性修復機能しかなく、ディスクのアンマウント制御すらおかしい．
上のを超簡単に説明する．
--------ここから
M1 Macは回復モードに入るとOSパーティションはアンマウント状態にでき、だからファイルシステムを修復することができるという建前になっている．
これをまともに信じてはならない．
このケースではFirstAidは能天気に
「
** The volume /dev/rdisk3s5 was found to be corrupt and needs to be repaired.
** Verifying allocated space.
** Performing deferred repairs.
** The volume /dev/rdisk3s5 appears to be OK.
」
なんてメッセージするが全然OKじゃない．
FirstAidにプログラムされたファイルシステムの整合性チェックに引っかかっていて、そしてリペアを諦めている．
要するにプログラムされている修復処理は実施できない状態なのだ．
で、「ま、OKってことにするよ」と言っているのである．
それで、腕に覚えのある人ならFIrstAIdから抜けてコマンドラインを叩こうとするだろう．
でfsck_apfs を実行するだろう．すると、
「
error: container /dev/rdisk3 is mounted with write access.
」
こんなエラーになる．
こ の ツ ー ル は マ ウ ン ト 解 除 を 試 行 し な い の だ ．
馬鹿め．
これを回避するには次のコマンドを実行しなければならない．明示アンマウントだ．
diskutil unmountdisk disk3
さらにもう一つコマンドを入れる必要がある．
そうしないと
「
error: failed to enable crypto I/O mode for container /dev/rdisk3: Invalid argument
」
こんなメッセージを見ることになる．FileVaultを解除しなければならない．わかるかこんなんで．
diskutil apfs unlockVolume disk3s5 -nomount
これでFileVaultのパスフレーズを入れて解除した後やっとfsck_apfsを受け付けて役に立たない中途半端なチェックを実行してくれる．
--------ここまで
全然簡単じゃなかった．申し訳ない．
それで結局、Acronisのレスキューブートを使って立ち上げ、ディスクユーティリティでメインのパーティションを吹っ飛ばしAcronisのバックアップからリストア修復した．
もうThunderbirdのメールデータだけ退避してリストア後戻す、という手慣れた作業でエラーは消えた．
ここのところAcronisのリストア成績は良い．このぐらいのスピードで戻ってくれるなら、リストアは全然怖くない．
とはいうもののクソみたいなファイルシステムに付き合うのも限界がある． 僕は強烈なディスクアクセスを伴う処理なんてさせていない． 動画作成をMBPで処理している人はたくさんいると思うが、データが読めなくなったり意味不明なフリーズが起きたら「ま、Macだしね」とニヒルな笑いを浮かべながらリストアしているのだろうか．あーヤダヤダ．
(20230908)
