IMAPメールボックスの危機 (2)

Imapのサーバーのユーザーディレクトリーに保存されているファイルの名前はMIMEではなく、UTF-7だそうです。

で、それを変換するperlスクリプトを作りました。作ったと言っても当該のCPANモジュールを呼び出すだけですが。

ただし、これには罠があって、CPANモジュールのIMAP-UTF-7の説明には間違いがあります。

use Encode qw/encode decode/;

ではなくて、

use Encode::IMAPUTF7;

としないといけません。ずいぶん昔から指摘されているのに、直っていません^^;

スクリプト付けときます。GNU GPL 3.0 or laterっちゅうことで。

#!/usr/bin/perl
# imapdecode.pl
# by I Hieda (JE1SGH), 22 Apr 2016
# GNU GPL 3.0 or later

use Encode::IMAPUTF7;

$filename = @ARGV[0];

$outname=Encode::decode('IMAP-UTF-7',$filename);
binmode(STDOUT,":utf8");

print $filename," : ";
print $outname,"\n";

使い方としては、

 for i in `ls`; do imapdecode.pl $i; done

などとします。

IMAPメールボックスの危機

注意(主に自分宛, 2024/10/30): 当記事執筆当時,IMAPサーバーはUW-IMAPでしたが,その後dovecotに変更したので,当記事の内容は現在は全く意味をなしません.

自分のメールの管理は、昔からIMAPサーバーを立ち上げてやっています。これは個人営業のクラウドのようなもので、サーバーにアクセスできる限り、自宅LANからも外部からも、パソコン、iPhone、iPadなどで保存したメールすべてを同様にアクセスできます。どこからでも同じように閲覧・保存・操作ができるということで、年々メールが溜まっていくわけです。

とは言えメールに関してはパソコンのトラブル、サーバーのトラブルなどで完全消失したことが過去には何度もあり、現在残っている最古のメールは2002年11月です。

人によっては数百通のメールがありますが、文字コードの破損などで、メールボックスの構造が壊れているというか、ほつれつつあるところがあります。

クライアントの種類、接続の状況によって、正常だったり、異常だったりします。と言うことで完全に壊れている、というより「ほつれている」状態です。たぶん、文字コードのハンドリングが完璧でないクライアントでいじったりしたのが、ほつれをひどくしている原因だと思います。

あんまりいじるとさらにひどくなりそうなので、そっとしておくことにしますが、うっかり削除したり、どうしようもないほど回復不能になったフォルダーの回復法をメモっときます。

  1. Thunderbirdを使う。Local Foldersの場所をAccount settingで確認しておく。
  2. バックアップがあることを確認した上で、当該のフォルダーを削除して、Thunderbirdはいったん終了。
  3. 壊れたメールボックス(フォルダー)の場所(path)を特定して、バックアップツール(Time MachineやRetrospect)からそれに対応するファイルを探し出す。
  4. 復活させたいフォルダーのファイル、”フォルダー名”と”フォルダー名.msf”を安全なところに復活させる。
  5. その二つのフォルダーを1でみつけたフォルダーにコピーする。
  6. Thunderbirdを起動して、Local Foldersにある復活させたフォルダーの中身を確認して、IMAPサーバーにコピーする。

不可視フォルダーや、pathなどについては、省略^^; たぶん、解る人にはヒントになると思います(たぶん^^; おそらく^^;; )。

気をつけなければいけないのは、Thunderbirdでフォルダーの中身をぶっ壊した場合、Thunderbirdで同じフォルダーを復活させてもその後の処理はかなり危険と言うことです。

Thunderbirdは、どうも、この件に関してはかなり劣悪です。Apple Mailはまだましですが、バックアップから復活させたメールボックスファイルをインポートする方法が解らないので、今回は使い(使え)ませんでした。

また、GMailにIMAPでいったん上げて、GMailのWeb UIでいじるのは良い具合です。ただし、また、自営のIMAPサーバーに戻す時にトラブったりしますが。

メールクライアントからは、同じフォルダー内にあるというイメージ。IMAPサーバー的には、一つのメールボックスファイルとなっている。

Retrospect

ああ^^;

少なくとも,オーストラリア赴任の時には使っていましたから,Retrospectとのつきあいは20年ほどになります.

OS X版になってから遅いのなんのって^^; で,新しいバージョンが出る度に,何十パーセント速くなったっていう売り文句なんですが,全く速度の向上が体感できません.

たかだか数GBの更新されたファイルの吸い上げは10〜30分で終わるんですが,そのあと,”Building Snapshot”という表示が出てからが長いです.で,どういう条件だと時間が長くかかるか(あるいは,短くできるのか)が全く不明で,一番長いクライアントは24時間くらいかかります.

最近のRetrospectのバージョンではRetrospect Instant Scan Advancedという新機能が含まれています.これは,クライアントのマシンでRetroISAというデーモンが動いて,事前にRetrospectに都合の良いカタログを作っておくようです.

ところが,私が個人用に使っているRetrospectはVersion 9とかで,クライアントがこのRetroISAでカタログを作ってもその恩恵には与れませんから,ただCPUサイクルを無駄に消費することになります(SSDの寿命も多少は縮めるでしょう).

ということで,それを止めたい場合は,

sudo launchctl unload /Library/LaunchDaemons/com.retrospect.retroisa.plist
sudo defaults write /Library/LaunchDaemons/com.retrospect.retroisa Disabled -bool true

(下記参照ページより)という,コマンドを実行しますが,クライアントのコントロールパネルにON/OFFのスイッチを付けないというところが,なんとも,馬鹿にしてますよね^^;

実は前週末,家族用のMac miniのSSDの内容が完全にぶっ壊れて,復旧作業をしたのですが,Retrospectは全く出番がありませんでした.

とにかく,一つの行程が30分から数時間かかることがざらなんです.たとえば,リストアするのに,保存されているディスクの内容を開こうとすると,そこで,何十分,選んで,何かの準備をするとまた何十分,最終確認で,違ったかなと思ってやり直すと,また何十分ずつを繰り返します.”Cancel”を押しても待たされることがあります^^;

結局Time Machine機能で,Time Capsuleから復活させました.こちらも,一晩かかりますが,設定は,たいして時間のかからない簡単な手順なので,すんなりと”実行”ボタンを押して,あとは寝て待てば良いだけです.

しかし,しかしなんですが,Linuxのバックアップは,Retrospectしかないんですよね^^; ということで,Linux用に残して使っている.それなら,ついでに,ということでWindowsもMacもバックアップしておく,という考えで,ずるずる引きずっています^^;

Macだけならば,Time Capsuleと外付けディスクで二重にTime Machineでバックアップするなどしておけば,十分だと思います.

自分宛のメモ

“Retrospectはついでにバックアップを取っているだけなので,復旧はTime Machineからすること”

参照ページ