2016年9月11日日曜日
Thunderbird メールデータの統合・再生
現在、主に使っているノートPCは、Windows7 から10にバージョンアップした際、すんなり移行できなくて、一度、7を最初から入れ直して10にアップすることになり、Thunderbird も新規に入れ直したもの。そのため、メールデータが途絶。一応、移行作業前にメールデータを保存してあるフォルダを、そのままコピーして取っておいたので、書き戻せば元に戻せたのだが…いつものことなんで、特にこだわる必要もないかと思い、新規に使い始めたせいでもあるのだけど…。
ただ、添付ファイルなど、必要になる場合もあるので、しばらく交信していなかった人のメールアドレスを調べるついでにデータ回復・統合法を調べてみたので、自分用の備忘録を兼ねメモ。ただ、バックアップとはいっても、Thunderbirdのメニューからファイル保存を行ったのではなく、通常のメールデータ保存フォルダを、他の場所にコピーして複製を残してあった、というケースへの対処法。
手順
1.メールデータのバックアップ、あるいは保存フォルダが残っていることが前提。
自分が今回試した方法は、Thunderbird の左側、メール・アカウントの下にある、ローカルフォルダに作ってある、メール振り分け用のフォルダ単位でメールを Thunderbird に認識させ、その時点で保存されているメールデータと統合したという方法。IMAPで運用している人には、当然、無用の話。
2.バックアップされているファイルは、「○○○.msf」というファイルとmsfの拡張子のつかない「○○○」だけのファイルでセット。○○○には、ローカルフォルダにあった各フォルダ名。
3.○○○が、現在使っている Thunderbird でも使っているものだと上書きされる心配があるので、リネームする。全然違う名前でも良いし、何文字か追加するだけでも大丈夫。例えば、○○○-tmp など。
4.○○○.msfと○○○の2つのファイルをセットで、現在のメールデータフォルダ(ローカルフォルダ側)にコピー。
現在の環境では "C:\Users\(ユーザー名)\AppData\Roaming\Thunderbird\Profiles\(アカウン名).default\Mail\Local Folders"。AppData のフォルダは、ファイルの表示設定を変更しないと、デフォルトでは見えないので、事前に設定を変更しておく必要あり。
5.統合したメールデータをコピーしたら Thunderbird を起動。一回では認識してくれないこともあるので(ファイルデータが大きい場合、読み込みに時間が必要だっただけなのかも…)、1~2分してもう一度起動すると、ローカルフォルダの部分にリネームしてコピーしたファイル名が、フォルダとして表示されているはず。そのフォルダを選択して、右側のメールリストにメールが表示されれば成功。手動になるけど、個々のメールを選択して、保存したいフォルダに移動させれば終了。念のため、メニューからファイルの保存を行っておけば、またデータが分断しても安心。
6.フォルダ内にさらにサブフォルダを作ってあった場合は、メールデータを保存してあるフォルダ内に「▲▲▲.sbd」というサブフォルダが作られていて、その中に、msfの拡張子のつくものとついていないものがセットで保存されているので、先ほどと同じように処理(ただし、サブフォルダとして回復させることはできないので、通常のフォルダとして認識させ、その後、サブフォルダに移動させる必要)。
以上。
(おまけ)
送信メールを示す「SENT」というファイルがあり、コピーする時、たまたま「SENT-old」としてコピーしたら、ローカルフォルダの中で「送信済みトレイ」と表示されて、専用のアイコンがついていた。偶然だけど、システムの予約語だったのかも…。
2015年8月16日日曜日
エラー:Unknown file type “vboxsf”
そうしたら、また共有フォルダが上手く機能しない様子。色々と設定を試しているうち「Unknown file type “vboxsf”」というエラーメッセージに遭遇した。これは初めて目にしたものだったので、ネットで検索したところ、次の記述を発見した。
--------
I've fixed mine using the following way:
1) Update system's packages
$ sudo apt-get update
2) install virtual box guest additions (referenced from here)
$ sudo apt-get install virtualbox-guest-additions-iso
3) Now install guest additional package (Crucial step! People generally miss this which creates an error “Unknown file type “vboxsf”)
$ apt-get install virtualbox-guest-utils
--------
国内の記事では見つけることができず、英語のページで発見したのが上記のコメント。この内容に従ったところ共有フォルダは利用できるようになった。
…が、今度は、ディスプレイのサイズを上手く調整できなくなってしまった。virtualbox の画面サイズを、ホストである windows7 のデスクトップ上に表示する時、最大サイズより少し小さく設定していたのだが、再起動のたび、デフォルトのサイズに戻ってしまう。guest additions を再度適用して kernel を再構築してもダメ。
その際、ターミナルの画面は従来の処理経過の表示と違って、「building …」となる部分でリンクの所在を表示する形になっていた。最終的には guest additions の適用は成功したってことで終了しているんだけど、依然として画面サイズの検出は上手くいかない状態。
そこで、今回、vboxsf というファイルタイプを認識させるため、iso ファイルをインストールする形を取り、そこから参照するスタイルになっているのが原因だと推測して、ターミナルで打ち込んだコマンドの内容をすべてアンインストールしてみることにした。(それでまた「Unknown file type “vboxsf”」が出てきたら、その時はその時で…(笑)。)
iso ファイルの方は remove しても「そんなものは無いぞ(ボケッ)」って怒られたが、utils の方は無事 remove 成功。そうして再起動したところ、めでたく画面サイズを、指定したとおりの形で再現することができるようになった。(めでたしめでたし…)
2015年7月18日土曜日
(何度目かの) 共有フォルダ設定方法の整理メモ
/media/sf_NAME
NAME は、ホスト OS 側で設定した 「名前」 の値。ただし、このディレクトリのアクセス権は、vboxsf ユーザーグループにのみ許可されているため、ファイルマネージャーで普通に覗こうとすると弾かれてしまう。それを知らなかったので、いつも sf_××× というフォルダができているのにアクセスできず不思議に思っていた。ゲスト OS 側の一般ユーザーから共有フォルダにアクセスするには、あらかじめそのユーザーを vboxsf グループに追加しておく必要があり、そのための書式が
sudo gpasswd -a ユーザ名 vboxsf
ということだった(らしい)。
したがって、VirtualBoxの共有フォルダの設定「自動マウント」にチェックしていると、システムの方では、「既にどこかにマウントしているぞ」と判断して、後からマウントしようとした操作をエラーとするらしい。そのため、
sudo mount vboxsf -t (共有フォルダ名) /media/マウント先
の記述は無視orエラーとなっていた可能性があり、何度もマウントできず悩んだ原因はここにあった様子…。でも、そうなると逆に、何度か起動と終了を繰り返しているうちに、これで有効になって使えていた理由が謎でもある…。
実際は、guest additions or インストーラのバグが原因で共有フォルダがマウントできないってケースもあるようなので、何が原因か、素人には調べても限界があるかな。…ということで、しばらくは vboxsf グループにユーザーを追加する方法で、共有フォルダを利用していこうと思う。
以上、以下のページなどを参考にまとめてみました。
参考:http://vividcode.hatenablog.com/entry/virtualbox/shared_folder
http://rubellum.hatenablog.com/entry/20110508/1304835867
2015年6月6日土曜日
Ubuntu 12.04 => 14.04 (32bit)
ただ、Ubuntu自体のバージョンは、12.04である必然性もないので、14.04を入れてみることにした。もともと、64bit版を入れていて上手く保存できない、ってのが事の発端だったので、32bit版の方を…。しかし、やっぱり上手く保存できない…。ということで、一度、12.04を入れて、それをupdateしてみることにした。
結果は、正解。ただ、Virtualboxから起動させると最初「File not found.」が3行出て、「Press any key to continue...」となるようになってしまった。
何が起こっているのか…ということで、いろいろ調べてみたら、どうやらGRUBがおかしくなっているらしいとのこと。参考にしたのはここ。
> http://mitaka1954.cocolog-nifty.com/blog/2014/08/ubuntu-1204-140.html
Webページとの理由とは違って、updateの途中で「GRUB」をインストールしない、という画面が出てきて、変更できなかったような気がする(ダメならやり直せばいいやくらいの意識でやっていたので余りよく覚えていないが…笑)。多分、その辺りが原因だろう。
そこで、アドバイス(?)に従うとこんな風になった。
$ sudo grub-install /dev/sda
[sudo] password for xxxxx:
Installing for i386-pc platform.
Installation finished. No error reported.
これで正常に起動するようになり、万事解決。
2015年5月6日水曜日
CaptureStream(Linux版) 導入顛末
しかし、XPもupdateが打ち切られ、それに代わるプラットフォームに移行することが求められていたのだけど、7にインストールするのも大げさな気がして(?)、語学ファイルをダウンロードするためだけに、ずるずるとXPを使っていた。もっとも、virtualboxの中のXPなので、他にはあまり影響がないだろうと思ってのことだったが…。
第一候補は、同じvirtualboxに入っているUbuntu。そう思って昨年以来、何度かトライしてみても自分の利用環境ではダメだった(Ruby版は、解説ページを見つけ、その通りにインストールしたら無事動いていたが、Ubuntuネイティブで動くものを入れておきたかったので)。最初は、プログラムの起動すらせず。フォルダを工夫したりしてそのうち起動はするようになってもファイルのダウンロードで失敗。保存フォルダのアクセス権を見直したり、何かのパッケージが不足しているのかもしれない、と思って、いろいろ検索して、そのページで解説されているパッケージをインストールしたり…。数回トライしたが全滅であった。
参考にしたWebページではどこも、ダウンロードしたファイルを解凍するとすぐ使える、と説明されていて、どうして自分のシステムではダメなのか分からないばかり…。そのうち、CaptureStreamに同梱されいてるffmpegを64bitのものに上書きする、と説明のあるページを発見。同梱されているものは32bitとのことで、解説者のシステムが64bitなので、それに合わせて…という記述だった。それでハタと気がついたのが、14.04にupdateした段階で、hostOSがWindows7-64bitなので、Ubuntuも64bit版をインストールしていたこと。
そこでvirtualboxに新たに32bit版のUbuntuをインストール。それにCaptureStreamを入れ起動させてみた。すると、あんなに苦労していたダウンロードがすんなり成功!あの苦労は何だったのかと馬鹿らしいことこの上なし…の状態になった(笑)。
ここまでは自宅のデスクトップPCの話だったが、同じことだと思い単身赴任先のノートに同じく32bit版UbuntuとCaptureStreamを入れて起動。ところが、プログラムは起動するもののダウンロードに失敗。本体のページの注意書きで「ダウンロードに失敗する時は、libva1/libmp3lame0/libass4のインストールを確認」と記述があったので、
sudo apt-get install libva1:i386 などとインストール。それでも失敗…??。
よく考えたら、自宅のPCでは、32bit版にgnome-shellも入れていて、unityではなく、主にそちらを利用しているので、こちらにもgnomeの拡張パックを入れてみると、無事ダウンロードも成功。どのパッケージが不足していたのかは不明だが、とりあえず目的は達成したので詮索はしないことにする。
ちなみに今回、共有フォルダを起動時にマウントするのに使うrc.localファイルに
sudo gpasswd -a ユーザ名 vboxsf
という記述を追加しておくと、共有フォルダを開く時、アクセス権がないと怒られなくなった(笑)。
2013年12月10日火曜日
一太郎2009 update
…しかし、一太郎が起動しなくなった。カスタム・インストールのため、ドライブ構成が標準と違うせいかと思い標準のドライブ、フォルダ構成にして入れ直しても、updateするとやはり動かなくなってしまう。
「JsFirst.DLL」が無いから起動できないので、再インストールしたらどうか…と言われる。
仕方がないので、すべて標準のままインストールしてそれをupdate。そこから再度インストール・ディスクのセットアップを起動して、インストール内容の修正を行い、順番に不要なサービスを削って行ってみた。
…そしたら、ヘルプだった。ヘルプをインストールしていない状態でupdateすると起動しなくなる…ということだった。
夜寝る前に気づき、あれこれ考えながら色々格闘したら、すっかり目が冴えてしまって、おかげで寝付けなくなってしまった。結局、うつらうつらしただけで翌朝を迎えてしまい、翌日は仕事にならんかった。updateを作ってくれるのは助かるんだけど、前提とするインストール条件を明示するか、もう少し対応に幅を持たせた作りにしてもらえたらいいのに…と思った次第(笑)。
2012年9月8日土曜日
VirtualBox 4.1.22 ExtensionPack インストール・エラー
久し振りの更新…(笑)。
VirtualBox を起動すると、新しいバージョンの案内があったので、更新してみた。一緒に Extension Packs もダウンローとして順番に更新…と思ったところ、VM 本体は支障なく Update できたんだけど、Extension Packs がエラーを出して更新できない。
再度やり直してみても同じで、エラー・メッセージを見ると、作業用のフォルダのリネームに失敗云々らしい様子。Extension Packs がダウンロードされていた user\.virtualbox の上位フォルダから書き込み許可に変更しても失敗するので、ググってみた。
参考にしたのがここ http://plaza.rakuten.co.jp/comapple/diary/201102230000/
自分が使っているOSは、いまだに化石時代の遺物(笑) winxp のhome edition なので、それも理由かもしれないけど、DLしたパッケージの解凍でトラブっている可能性がありそう。…ということで、DLしたパッケージは、拡張子のない状態だったが、その末尾に tar.gz を付加。それをアーカイバーで解凍(今はlhaplusを愛用)。[C:\Program Files\Oracle\VirtualBox ]の中に ExtensionPacks 用のフォルダがあるので、解凍された内容を上書きコピー([C:\Program Files\Oracle\VirtualBox\ExtensionPacks\Oracle_VM_VirtualBox_Extension_Pack]の中)。
VirtualBox から仮想マシンを起動させ、Additional Package をインストールさせると、ちゃんと4.1.22用のパッケージがインストールされ、正常終了。
結局、パッケージに埋め込まれている解凍処理が不十分だっただけのことらしい。それなら最初からアーカイバーを使って明示的に処理できる方法も示してくれた方が、中途半端に自動化するよりよっぽど親切。
…と思ったわけでした。
…とここまで書いてプレビューさせると、改行がすべて無視されていて、全部が1文になっている。新しいインターフェイス何たら~と出ていた影響だな、と思って調べたら、<p><p/>を入れてやらないとダメらしい…ということで、修正したのが今回のエントリーでした。