瓦礫を拾い集めて城壁を再構築する

ThunderBirdは心強いバートナーとして長く付き合えるような気がしているが快適な作業環境を確立するためにはまず,長い年月の間に積み上がったGmailのパイルを崩さなくてはならない.作業はある意味着々と進んでいるが,問題が無いわけではない.一部フォルダでGmailからローカルに移動できないケースが起きている.メールの移動をフィルターを使って実行しても,メニューから「フォルダに移動」を実行しても,さらにフォルダ内のメールを全選択ないし部分選択して別フォルダにドラッグ&ドロップしても動かすことができない状態になっている.原因は本数が多いため転送量の関係で何かしらの(通信経路的な)トラブルが生じているのではないかという気がする.IMAPではサーバー側と同期を取らなくてはならないのでそれがネックとなっている可能性がある.

どう対処すればよいか?フォルダ名が英字のフォルダは発信元が単一の大きなフォルダが一つ,混在したフォルダ一つを残すだけという状態になっている.それぞれ4750本,45本入っている.いや,もう一つ残っている.中が空っぽなのに削除できないというフォルダだ.このフォルダが削除できない理由はわからないが,Web上で操作できるかどうか見てみよう.⇒このフォルダはすでにWeb上では消えている.このフォルダはしばらく放置して小さい方のフォルダを先に片付けることにしよう.

片付いた.空のフォルダはGmal上には存在していないので,ここにメールを移動しようとしても元の位置に戻ってしまう.大きな単一フォルダにフィルターを掛けたところ,Gmailとの接続が切断されてしまった.日本語フォルダフォルダ名を持つフォルダの方に移ることにする.

ほぼ片付いたが,大きいフォルダが2つ残っている.日経ビジネス(11157)とCNET Japan(4935)だ.分割すれば移動できるのだろうか?⇒小さいポーションなら大きいフォルダの中でも実行できるようだ.今すぐ実行→停止ボタンが表示されるまでに時間が掛かっている可能性もある.⇒せめて砂時計でも出してもらえるといいのだが…一度だけ下記のようなパネルが出たが,完了できた.フィルタの数は全部で126個になった.アーカイブに入っているメールだけで23,295本ある.

image

要領は,大きなフォルダにフィルタを1本掛けるのではなく,5~600本くらいの比較的小さな単位でファイルを選択し,「アーカイブ」を実行して全フィルタを適用するというのが一番速く確実に完了できる.まとめて実行する単位はもっと大きくてもよいが,おそらくリザーブしているメモリサイズが限界になっているために限界がある.もちろんIMAPで同期を取るためのトラフィック的な制限というのも影響する.再起動すると状態が回復する場合もある.⇒Gmailのダウンロードは完全に完了した.Webにはもはや新規受信メールしか存在しないという状態になっている.これで「メールの読み込み」に要するオーバーヘッドは完全に解消した.さて,このあとどこまでやるか?というのが問題だ.

ネットから遮断されていた2016~2018年の前後で大きな断絶がある.それ以前のデータは大きく破損したまま放置状態になっている.2018年以降の分に関しては一応ここまでで整理できたと言ってよいが,それを 2016年以前のデータに架橋して地続きのものとしなくてはならない.

蓄積された情報を活用するためには「検索」が機能することが最重要なポイントだが,その点がThunderBirdに移行してもっとも気がかりな部分だ.TBの内部にあるメールはGrep機能のある検索ツールでもエクスプローラの検索でもアクセスすることができない.試みにTBの検索ツールでローカルフォルダ内の全文検索を仕掛けてみたが,どうしようもない程遅い.ただし,TBの「クイックフィルタ」というのは相当高速でこれなら十分実用になると思われるのだが,使い方がまだよくわからない.

検索条件は特に何も指定せず,ただ与えらればキー文字列を無差別に適用して検索しているようだ.ヒットしたメールのタイトルをクリックするとそれに関係したスレッドをツリー後続で表示することができる.これもかなりおもしろい.検索結果は「関係者」と「フォルダ」で絞り込むことができる.しかし,「馬場 英治」で検索して628通しかヒットしないというのはやや疑問がある.多分,タイトルと本文しか検索していないものと思われるが,それでも少な過ぎる.ヒットしているのはほとんどGmailのアーカイブばかりだ.実用的に使うためには,Gmailのアーカイブはすべて外に出すしかないかもしれない.また,WLMからインポートするまえに重複ファイルの削減をやっているはずだが,どうも相当量残っているような感じだ.重複ファイル検査を重複がなくなるまで繰り返す必要があったのではないだろうか?TBのメールは単体ファイルではないので,もはや重複検査ツールを使うこともできない.

もし,どうしてもというのであれば自分でプラグインを開発しなくてはならないということになる.そこまではさすがに手が回らない…ともかくここでは割り切ってGmailをすべて外に出してしまうことにする.Gmailのアーカイブは1階層のフラットな構成になっているので,emlとしてエクスポートすることができる.ここでThunderBird Dataのバックアップを取りたいのだが,すでに8GBを超えているのでEドライブには入らない.⇒microSDを使うことにする.microSDがドライブとして認識されるのなら,ここを使うのがもっとも早いのだが…ThunderBirdから見えているかどうかチェックしてみよう.⇒いや当然ながら見えている.microSDとUSB3.0はどちらが速いのだろう?⇒microSDはUSB2.0とほぼ同等の60MB/S程度だ.USB3.0は2.0の十倍程度速いと言われているので段違いということになるのだが…ともかく試してみよう.

アカウントごとに保管場所を指定する必要があり,さらにローカルフォルダの位置を指定するため3回再起動が必要になる.最後のローカルフォルダの設定→再起動でエラーが2つ出た.一つはアドレス帳不在,もう一つは何やらファイル名が長過ぎるというエラーだ.⇒アドレス帳には今のところ一人しか登録されていないが,読み込めている.TBは個人用アドレス帳と記録用というのを持っているが,どう使い分けるのだろう?

さすがにGmail2020(48003)を読み込むのには少し掛かるが,Gmail2016(5797)くらいならすぐに出る.選択したメールは瞬時に表示されるので,実用的にはこれで十分ではないかと思う.Chromeのダウンロードフォルダも指定できるし,Cドライブのユーザフォルダもほとんど外部ドライブを指定できるようなので,Cドライブの代替として十分microSDを使うことができるのではないだろうか?microSDにはまだ200GB以上の空き領域がある.⇒さすがに,検索を掛けるとかなり効くようだ.10倍より遅いかもしれない.これは伝送速度というよりドライブのアクセス速度の差かもしれないが…ちょっと使い物にならないと思う.Gmailを取りに行っているのではないからここまで掛かるというのは問題だ.というか,行ったきりで返って来ない.⇒やっと出た.検索結果は同じ628件だが…⇒やはり,戻すことにしよう.microSDはせいぜいバックアップに使うのが関の山だ.無線HDの導入も考えていたが,WiFiの伝送速度はさらに遅いので,かなり考えものだ.結局USB3.0で接続するHDが最速ということになる.

Gmailのアーカイブを一度エクスポートしてから削除しようとしているのだが,どうもあまりうまく行っていない.48011本入っているGmail 2020はemlでエクスポートして36397本になってしまった.5799本のGMail 2016は612本しか生成していない.Gmail 2017(4973)は0でしかもSTOPボタンを出したままだ.どうも何かおかしい.emlで出力するのが苦手なのだろうか?それにしても具合が悪過ぎる.一旦エクスポートを中止して出直そう.⇒今回は単純な標準的エキスポート方式を採用した.これ以外の方法ではインポート不能なので意味がない.処理は単にファイルを書き出すだけなのであっという間に終わってしまう.3つのフォルダが入っているフォルダをZIPでエクスポートするというのもやってみた.⇒Gmailのアーカイブをすべて削除した.

フィルタから漏れて月次アーカイブに入っているメールがかなりある.おそらく,すべてのフィルタが整備される前に処理されたためではないかと思う.もう一度フィルタを通してみよう.確かに動かないファイルもある.おかしい.フィルタが1件を残して完全に空になっている.⇒フィルターはアカウントごとに独立に管理されている.ローカルフォルダには独自のフィルタリストがある.フィルタの完成型というのはGMAILにしかない.これを分配する必要がある.⇒月次アーカイブをフィルタリングする前に最終的なフォルダ構成を固めておいた方がよい.ファイルのフォルダ間移動は思ったより時間が掛かる.フィルタの最後に未分類というのを置いて無条件でそこに移動するようにしておこう.いや,アーカイブで移動しているのだから,月次に必ず入るはずだ…⇒BIGLOBEフォルダが消えている.フィルタがあるのだから,作ってあるはずなのだが…ときどき下記のパネルが出る.

image

フィルタリングはあとでやり直すことができるので,おそらくマルチスレッドで処理しているためリソースの取り合いになっているのだろう.「うまくいかないときは止める」というのがTBのポリシーのようだ.TBの動作の方ががWLMよりも安定しているというのもこのストラテジーの効果かもしれない.つまり,コミットメント(動作の完結)を強く意識した作りになっている.

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です

CAPTCHA