大文字/小文字を区別「する」から「しない」HDDへの移行方法

以前の投稿でさらっと作業内容の詳細を述べずに進んでしまった次の部分について追記します。

解決方法は「大文字/小文字を区別しない」ディスク形式にするより他無いらしく、一旦別の「大文字/小文字を区別しない」ディスクを用意してデータを往復させることにしました

情報源: photoslibraryを置くディスク形式 – hkitago software development

写真アプリのライブラリを「大文字/小文字を区別する」から「大文字/小文字を区別しない」ディスクへコピーしようとすると当然次のようなエラーを返してきます。

“写真 Library.photoslibrary”はコピーできません。コピー先ボリューム上に同じ名前の別の項目が存在しており、コピー先ボリュームはファイル名の大文字/小文字を区別しません。

そこでまず思いついたのが、TimeMachine バックアップが登場する以前に利用していた rsync コマンドでした。

http://hkitago.tumblr.com/post/169802245421

単に自分で配置したファイル群であればこのやり方で問題が無いのですが、iTunes や写真アプリのライブラリは別途データベースでファイルを管理していて整合性が取れなくなってしまう懸念があって却下しました。

次に考えたのが、ライブラリをコピーする前に実際にどのファイル名が大文字小文字違いで重複しているのかを調べて、iTunes や写真アプリ内からファイル名を変更すればデータベースもそれに応じて変更されるだろうというもので、次のコマンドを利用しました。

http://hkitago.tumblr.com/post/169756177861

iTunes ライブラリではアーティスト名やテレビドラマ名の先頭が大文字のものと小文字のものが混在していたので、アプリ内からそれぞれ変更して対応することができました。

ところが写真アプリでは、編集した写真のファイル名の拡張子を小文字にしてデータを複製するという古い iPhoto 時代の仕様が悪さをしていたようで、アプリ内からのファイル名変更ができず10枚ほどしかなかったこともあってこれらのファイルをファインダー上で順に削除しました。

そして TimeMachine の「今すぐバックアップを作成」を実行し、「大文字/小文字を区別しない」ディスク形式へフォーマット後にデータを3日ほど掛けて戻しました。

photoslibraryを置くディスク形式

Bluetooth の仕様が変更になった影響でポケゴープラスが使えなくなった問題が解決したのでようやく iPhone を iOS11 に更新し年末年始に撮り溜めていたカメラのデータを High Sierra の写真アプリに取り込もうとしたらこのようなエラーを表示しました。

この “jpegvideocomplement” を検索語に調べてみると、写真アプリのデータである photoslibrary が格納されているディスク形式が「大文字/小文字を区別」している場合に起きるということが分かりました。

http://hkitago.tumblr.com/post/169719340056


また原因を同じとして起きる問題に Live Photos (ライブフォト) を読み込めなくなることがあるようで、実際に High Sierra に更新する9月末以降のライブフォトがライブラリにありませんでした。

解決方法は「大文字/小文字を区別しない」ディスク形式にするより他無いらしく、一旦別の「大文字/小文字を区別しない」ディスクを用意してデータを往復させることにしましたが、同じディスクに置いていた iTunes ライブラリなど含めて 2.5TB ほどあるので時間が掛かって仕方ありません。

また関連して、少し前に画面撮影のデータが読み込めない問題があったのですが、


ファイル名に時間を付けないことで回避したように思えて、上述したディスク形式の問題で結局読み込めないという羽目になっています。

今回の教訓として iOS11 と High Sierra へ移行するにはディスク形式に注意すべきでしたが、単に APFS の内蔵ディスクを使う一般的な環境下であれば特に気にする必要がありません。

http://hkitago.tumblr.com/post/169719429926

ただ APFS は SSD に最適化した形式なので、外付け HDD は Mac OS 拡張 (HFS+) のままで十分かと思います。今後写真データは増えて行く一方だと予想できるので、一時的な作業場所として APFS の内蔵 SSD と保管用の HFS+ の HDD とライブラリのデータを分けて管理する必要があるのかなと感じると同時に、写真アプリは起動時にオプションキーを押すことでライブラリの切り替えが容易になっていますが、アプリ内でデータを別のライブラリに移動するような機能があると便利な気がしました。

参考:

ファイルパスをURLに置換してSafariで検証するAppleScript

最近の GUI アプリは AppleScript を呼び出すメニューを持っているので、例えばエディタアプリで書いているコードを Safari で検証したいという時にブラウザでリンクの遷移を辿ったり URL バーに入力する手間が必要なく表示することができます。High Sierra の対応の問題から TextWrangler から CotEditor に乗り換えたことから先に使っていた AppleScript を編集したので紹介します。

今回はユーザディレクトリのサイトフォルダの中にあるファイルを対象にしましたが、MAMP やサイトルートにあるファイルを編集している環境では先頭二行のプロパティを編集してください(もちろんユーザディレクトリ名も)。後半では開発メニューのコンソールを同時に開くようにしていますので最初に使いたいもののショートカットキーにすると良いでしょう。

Coda にも Safari.scpt が同梱されているので、これを改編すれば file:/// スキームでの受け渡しを変更することができるのでお試しください。また Google Chrome を呼び出だす事へ流用する事も容易かと思いますので是非。

参考:

Audio MIDI設定でモニタ音量を調節する

JavaScript の createOscillator で出力した音を録音しようとして過去投稿を引っ張り出してきたのだけど、High Sierra の Audio MIDI 設定アプリのバージョン3.2 (3.2) でモニタする音量を調節することができなくて、一つ変更点がある事が分かりました。

以前は「複数出力装置」に入れ子になっている「内臓出力」にある音量を調節すればよかったのですが、そこが選択できなかったので、並んでいる「内臓出力」から設定することができました。


また、両方のチャンネルのスライダをマウスドラッグで同時に動かすキーコンビネーションがあったような気がしましたがうまくできなかったので、デシベル値を直接入力しました。

参考

HDDの物理障害をDIY復帰

Thunderbolt で iMac に接続していた EyeTV の録画用途に3TBの3.5インチハードディスクを使っていました。


深刻な物理障害は3回目ということもあり、バックアップなどの準備は問題ないのが幸いでした。


と思って検索してみるとこんなのがありました。


アマゾンで安価だったのですが、今回は外れ製品だったようです。


しばらくするとヘッドの異音はなくなり、こんな希望が見えたのでメールで問い合わせてみたところ、PCB 故障の疑いがあるということでした。

http://hkitago.tumblr.com/post/168312509896


そこで回路の修理に無水エタノールを近所のドラッグストアで買ってきました。

eBay で交換用の基板もあったのですが、ファームウェアを偽装するのに一度大陸へ送還するという面倒さもあって断念し、データと電源部分の接点を綿棒を使って拭いてみました。

真ん中上と右下に二つあるネジ穴近くにある3箇所の接点です。

すると、なんということでしょう。


接点復活スプレーという選択肢もありましたが、成分が精密過ぎや価格、など考慮した結果。


結構残っているので眼鏡のレンズ拭きに毎日使っています。

http://hkitago.tumblr.com/post/168313351751


最後に、誤字埋込ばかりで失礼しました。

参考:

High Sierraで不明なログイン項目を削除する

High Sierra へ移行してから気持ちが悪かった事の一つに、システム環境設定>ユーザとグループにあるログイン項目に不明な項目が30個ほど並んでいるという現象がありました。

公式のサポートフォーラムでも同様の質問があり、従来の ~/Library/Preferences/com.apple.loginitems.plist やキャッシュファイルの削除という方法が使えなくなってしまいその時点では有益な回答がありませんでしたが、一ヶ月ほど経ってもう一度確認してみると解決方法を見つけた人がいました。

http://hkitago.tumblr.com/post/166022085256

具体的には、~/Library/Application Support/com.apple.backgroundtaskmanagementagent/backgrounditems.btm をゴミ箱やデスクトップなどに移動して再起動すると直ります。

実際には参考にあるギリシャ語サイトを先に見つけましたが、投稿の日付を見るとサポートフォーラムの方が早いようで流石本家は違うなと感心。

参考:

photoanalysisdプロセスの挙動 High Sierra編

近年更新毎に何かのプロセスが悪さをしてくる MacOS ですが、引き続き photoanalysisd プロセスが昨年のものとはちょっと違った挙動をしていたので紹介します。iTunes と 写真アプリのライブラリは 4TB の外付けドライブに置いているのですが、排出しようとした時に次のようなエラーを返してきたことで発見しました。

そこで lsof コマンドを使って調べてみると、photoanalysisd プロセスが写真アプリを起動していないにも関わらず常時ライブラリの中にあるデータベースファイルを読んでいることが分かりました。これは OS の起動直後から開始しているようで、アクティビティモニタを見ても CPU 時間が圧倒的な数値を記録しています。

hkitago$ sudo lsof | grep /Volumes/TOURO\ Desk/
photoanal 497 hkitago txt REG 1,18 32768 6114807 /Volumes/TOURO Desk/写真 Library.photoslibrary/private/com.apple.mediaanalysisd/MediaAnalysis/mediaanalysis.db-shm
photoanal 497 hkitago 29u REG 1,18 45486080 6114800 /Volumes/TOURO Desk/写真 Library.photoslibrary/private/com.apple.mediaanalysisd/MediaAnalysis/mediaanalysis.db
photoanal 497 hkitago 30u REG 1,18 4152 6114806 /Volumes/TOURO Desk/写真 Library.photoslibrary/private/com.apple.mediaanalysisd/MediaAnalysis/mediaanalysis.db-wal
photoanal 497 hkitago 31u REG 1,18 32768 6114807 /Volumes/TOURO Desk/写真 Library.photoslibrary/private/com.apple.mediaanalysisd/MediaAnalysis/mediaanalysis.db-shm

「強制的に取り出す」を選択すると取り出すことはできた(データベースファイルの破損も気になる)のですが問題は起きなかったので、このことから設計志向を察するにメディアファイルを外付けディスクに配置することは例外なのかと思う一方、近年の SSD の普及などから内臓ディスクの容量は小さくなっていることや、iCloud ストレージを売り出したい意図などを考えると唸ってしまうものがあります。

関連して mediaanalysisd プロセスが DarkWake (ディスプレイスリープ)時に CPU を常時 50% ほど使っていることがあったりとやはり OS アップデートは人柱になること請け合いで、当面は iTunes や写真アプリを使わない時は外部ディスクを排出しておくという措置しかなさそうです。ただ、妻のアカウントでは状況が同じにも関わらず問題が起きないので発生条件は不明なのが不思議なところで、解決方法をもう少し模索したいと思います。

参考:

SSDを増設したiMacを調整

SSD を増設して起動ディスクにした iMac はその後 Apple Hardware Test を行ったところ次のような 4SNS/1/40000000: TH00-9.000 というエラーを返してきました。これは電源分岐を行ったことが原因でハードディスクの温度センサーが接続されていないために起こるようで、言われてみればファンの音が若干大きいかなという気がしたので、iFixit の方法に習って SSD の電源をマザーボードから直接引っ張ることにしました。

電源ケーブルは 922-9862 という商品コードらしいので、eBay で検索して $5.29 (Free international shipping) で中国から発送のものを購入しました。

前回の作業で分解の要領は得ているので淡々と作業を進めて行ったのですが、購入した電源ケーブルの接続部分が逆方向に曲がっていたので両面テープを貼り直し SSD を裏返してくっ付けることになりました。

再度行なった Apple Hardware Test は問題もなく、ファンもおとなしくなり、ようやく修理完了です。

最後にハードウェアネタが続いた余談で、”Apple is Really Bad At Design“ という記事に、電子レンジやテレビを例に「多くの人は部品を交換しないで本体を買い替えるんだよ」というコメントがあり、今回の作業を終えた後だけあって興味深く読みました。

参考:

iMacにSSDを増設

注意:ここで紹介した電源を分岐する方法は、Apple Hardware Test でエラーとなるので、電源を直接マザーボードから引く方法について書きました。「SSDを増設したiMacを調整

開発用途の機種に未だ iMac Intel 21.5インチ Mid 2011 EMC 2428 を使っています。購入時は 8GB だったメモリ容量は3年ほど前に Parallels と Photoshop の同時利用で重たくなったので最大 16GB に増設したのですが、近年は Xcode と Android Studio の同時利用に加えて、ハードウェア買い替えの目安の一つである IME(インプット・メソッド・エディタ)の和英文字入力切り替え時、特にライブ変換の際にもたつきと引っかかりが感じられるようになりました。その度にアクティビティモニタから日本語入力プログラムのプロセスの強制終了して騙し騙し使っていましたが、丁度(改造に失敗しても潔く買い替えの理由になる)iMac シリーズの刷新の噂もあり内臓 SSD を設置して起動ディスクを変更することにしました。

もう今更感たっぷりな作業なのは恐縮ながら Amazon で用意したものはこちら。

余談で SSD は 2TB が激安価格だったので一度挑戦しましたが、案の定返金されて 525GB を買い直しました。


SSD の固定は Vintage Computer のキットを使わずにホームセンターで買ってあった両面テープにし、

前例報告は多々あるので作業を要約しますと、OWC が提供しているインストールビデオの通り片方に二枚貼り DVD ドライブ裏の曲面に合うようにしました。

マザーボードの背面側から、シリアルケーブルは下から回すという説明だったのですがヒートシンクに沿って通っていた黒いケーブルがあったので上方向にしました。

その結果 SSD 上部で折り返す羽目になってしまったので、0.3m の短いものでも良かったなと少し後悔しました。

最終的には下L型の二股電源ケーブルのお陰でヒートシンク部分と衝突することなくうまく収まりました。


最後に失敗談として、HDD のサーモセンサーのピンが抜けずマイナスドライバで押したところどこか遠くの方でカラ〜ンと音がしてプラスチックの接合部分を無くしてしまいました。幸運なことに金属部分は残っていたので組立時には iFixit の拡大図で極を確認しラジオペンチで差し込み絶縁テープを貼っておきました。(焦って写真がピンボケ笑)

起動後に元の内臓 HDD からデータを移行し sudo trimforce enable を実行し完了です。Fusion Drive 化も検討しましたが、ファイル配置が自動的に決定されることがなんとなく嫌だったので却下し、SSD をシステム用に、HDD をデータ用として運用しています。デスクトップ機種でシステム終了することが少ないため起動時の速度に喜びを感じることが少ないのですが、Parallels などのアプリの起動時や IME 切り替えの滑らかさなど、OS の更新による快適さも考えられるので結局買い替えをまた逃すことになってしまいました。


それでも片方の USB 2.0バスが逝ってしまったり限界がかなり近くなっていることは間違いないので、子供に譲るまでもう少し頑張ってもらいたいところです。

参考:

Chromeブラウザのトップサイトを変更する

近年 Netflix や DAZN と言ったストリーミング配信サービスが充実してきました。開発環境では Safari ブラウザを使っていますがこれら動画配信系のサービスを利用するとエラーを起こして止まってしまうことがよくあったので Google Chrome ブラウザを使用することにしています。その際に、Google Chrome ブラウザで新規タブを開いた時の「起動ページ」に表示されている8つのページリンクのサムネール、これを Safari ブラウザでは「トップサイト」と呼んでいてドラッグ&ドロップのマウス操作で追加操作ができるものの、Chrome ではページの読み込み回数でのみの判定となっていて且つ期待した様に追加ができないという挙動があったので調べてみました。

まず辿り着いた StackExchange では、Chrome のデータファイル Preferences に記述されている locations の値を編集すれば良いということが分かったので、macOS でのファイルパス ~/Library/Application Support/Google/Chrome/Default に移動して探してみたところ、該当する値がありませんでした。そこで回答の2つ目を見ると、2012年にリリースしたバージョン 17.0.963.56 以降の Chrome ブラウザは Preferences テキストファイルの記述によるデータ管理を止めて SQLite に変更したことが分かりました。

同じ Default 内に Top Sites という拡張子の無いファイルがあったので DB Browser for SQLite で開いて見ると thumbnails テーブルにずらずらと該当データが保存してありました。

url_rank 項目の値順に左上から並ぶことになっていると推測できるのですが、この状態でもトップサイトにサムネールが表示されないのは問題です。

http://hkitago.tumblr.com/post/164159265281

この理由は、トップサイトの各サムネールをマウスオーバーすることで表示される右上の「バツボタン」を押し消去すると Preferences JSON ファイルの most_visited_blacklist キーに MD5ハッシュで短縮した redirects 項目にある URL の値を格納し、起動ページを表示する度に参照していることが原因でした。現時点(バージョン 61.0.3163.39)でこの仕様ですと、過去によく閲覧してトップページに表示されていたサムネールでも、一旦バツボタンを押して消去してしまうと再びトップサイトに加えることができないというもので、実際に DAZN のサムネールはあったのですが、まだコンテンツが不足していたことからアカウントを作成しなかったのでバツボタンを押してサムネールを消去していました。

ということで SQLite データはそのままに、Preferences JSON ファイルを TextWrangler で most_visited_blacklist":{} と編集し保存、Chrome の起動ページに8つのサムネールの表示を確認し、改めて表示させないサムネールのバツボタンを押しました。ただ、DAZN サムネールの画像が表示されておらず SQLite データを確認したところ、 thumbnails テーブルの thumbnails 項目が NULL となっていたため、適当に画面のスクリーンショットを 424×284ピクセルの JPEG データに変換して BLOB データとして格納しました。

「利用頻度の高いトップサイトに表示させたくないから二度と現れることがないブラックリスト行き」という設計は如何なものかとは思いますが、データの移行からと思われる url_rank 項目の値に -1 を持っているものもあったりと、今後の改善に期待したいところです。

参考: