2003/12/04(木) [n年前の日記]
#1 本人達が切羽詰れば詰まるほど周囲にはその光景がコメディに見えてくる
白い巨塔。最後のシーンで笑ってしまった。
[ ツッコむ ]
#2 [pc][web][linux][debian] メールデータの変換
そろそろEメール利用環境を、Win98 + OutlookExpress6（以下OE6） から Linux + ○○ に移行する準備を、と思ったのであります。
◎ OE6のメールデータ(.dbx)をmboxに変換 :
方法が
_こちらのページ
で解説されてた。Linux、あるいはOE6以外のメーラにおいては、
_mbox形式
でメールデータを扱えばインポート・エクスポートに使い回せる模様。csvみたいなものかも。ということで、まずはOE6のメールデータファイル = *.dbx を
_OE5Conv
なるフリーソフトを使ってmbox形式にする。
*1
試してみたら .txtファイルが出てきた。なるほど、この中身がmbox形式か。…ちょっと待て。このツールは1ファイルずつしか読み込めないのか。自分の環境では133個の.dbxがあるんですけど。手作業でやってたら死ぬる。何か方法を考えないと。…危ない危ない。ドキュメントはちゃんと読もう。複数の.dbxをD&Dすれば連続変換できると書いてあった。早速実行。133個の.txtが出てきた。余計なスクリプトを書かなくて済んだ。助かった。
◎ 変換前のフォルダ階層はユーザ自身が把握してる必要がある :
'hoge.dbx'と'hoge (1).dbx'があるのが不思議だったのだけど、中身を見てみたら、どうやら受信と送信に対応してるらしい。' (1)'がついてるのは送信メールのデータ。…嘘。早とちり。受信・送信に関係無く、同名フォルダがあった場合に、' (1)'がついたdbxファイル名になるだけの話。つまりファイル名のみでフォルダ階層を推測する事は難しいわけで。さあ困った。…事前にOE6で全てのメールを一つのフォルダにまとめてから作業を行うしかない。作業やり直し。しかもフォルダのD&Dは手作業だし。トホホ。
*1: *.dbxの格納場所は、OE6のメニューから、ツール → オプション → メンテナンス → 保存フォルダ、で確認できる。
[ ツッコむ ]
#3 [pc][web][linux][debian] メーラは何がいいだろう
やはり
_Sylpheed
であろうか。しかし、
_Mew
も気になる。もしかするとMewを使えば、WinとLinuxで同じメールデータを使えるかもしれぬ。…
_甘かった。
「MewはMH形式=1メール1ファイルで扱うので、メールの数が多いと確実にディスクを使い果たす」と書いてある。ダメじゃん。…いや待て。SylpheedもMH形式らしい。するとどっちもダメなのか？ …扱えるメール最大数の問題はさておき、要するにMH形式で管理するメーラを使えばWinとLinuxでデータを共用できるのかも。わかんないけど。
◎ _Sylpheed for Win32 :
なんだ。Win32版もあるのか。だったらMewに拘る必要もないか…。
◎ とりあえず気になるメーラを列挙 :
この記事へのツッコミ
[ ツッコミを読む(2) | ツッコむ ]
#4 [pc][linux][debian] メールデータ管理形式とファイルシステムの関係
_前記事での解説ページ
の注意事項をよく読んでみると、「メール数が数千〜1万になると、FATの場合はディスクを使い果たすが、FAT32なら大丈夫」と書いてあった。…FAT32だってFATじゃん。ここで言ってるFATとFAT32は何が違うのか。なんだか横道に逸れてきた。
◎ FAT12 :
FATと一口に言っても、
_FAT12/FAT16/FAT32/VFAT
がある。もしかすると、前述の「FAT」は「FAT12」の事かもしれない。なぜなら、
_FAT16/32ならサブディレクトリ内に65534個のファイルを作れる
ので制限にはならないだろうから。ということはよほど古い環境でもない限り問題はないということか。
◎ FAT16/32 :
いや、FAT16/32でも場面によっては厳しい。
_このページ
には、「ファイル名がMS-DOSの8.3形式に合わない場合、余分にディレクトリエントリを使う」と書いてある。
*1
ということは、FAT16/32においてサブディレクトリ中に保存できる最大ファイル数は65534個に遠く及ばないのが実態ではなかろうか。となるとMH形式で管理するメーラが1メールをどのようなファイル名で保存するかが重要になってくる。それによってFAT16/32上で扱えるメールの最大数が変わってくるのだから。…なるほど、OEがメールデータをフォルダ単位で.dbxにまとめて管理するのはFAT16/32の制約上自然な流れだったのか。そうなると前述のメーラは何故に各メールを1ファイルにまとめて管理しないのか疑問が湧いてくる。つまりは、Linuxも含めたUNIX系OSのファイルシステムはファイル数に関してFAT16/32ほどの制約を持っていないということだろうか。
◎ ext2,ResiserFS :
やはり、
_そういうことらしい。
ext2の場合、実測値でも、1GByteで257000個のファイルを作れる可能性があるのだとか。なるほどFAT16/32より随分と制限が緩い。1メール1ファイルとしても破綻しにくいのだな。…それはともかく「ReiserFSが45秒で終るのに、ext2は20分経っても終らない」なる話も目に入った。ext2系はファイル数が多いとそんなに遅いのか。失敗したかな。debianインストール時にext3ではなくReiserFSを選択しておけば良かったか。しかし現状ではResiserFSを読めるWin98用ツールは存在しない。
*2
Win98とのLinuxのデュアルブート環境においてトラブル発生時を考慮した場合、ReiserFSの導入は躊躇するよなぁ…。
[ ツッコむ ]
以上、1 日分です。
MHですと フォルダ/1 フォルダ/2 とメールが保存されていますが、アーカイブフォルダ形式ですと フォルダ名.zip になっていて、その中に 1 2 3 とメールが保存されていますのでディスクエントリの節約になります。
大量のファイルが格納されているZIPファイルを操作すると読めなくなることがありますが、ZIP形式にはcenter recordが壊れやすいという宿命があるらしく、修復するツールやcenter recordで無いファイル名を格納しているrecordを読んで展開するアーカイバなどを使うと直せるようです。
基本的にWanderlustは外部プロセスを使わない設計になっていますので、Meadow/Emacsさえ導入していれば何とかなるのが利点じゃないかなと思います。(特にWindowsは元々標準入出力をパイプで繋いで色々やるように出来ていないのを引きずってますから)
不勉強なもので、そんな形式も扱えるとは知りませんでした＞Wanderlust
なるほど、これはたしかに便利そう。ちと調べてみないと、ですな…
とはいえたしかに、ファイルが壊れた時のダメージを考えると、アレですね…
http://home.riise.hiroshima-u.ac.jp/~nagato/man/sylpheed/mh.html
といっても、自分が現在使ってるOE6も、1フォルダ1ファイルで扱ってるし。
そのへんの危険性は、今までと大して違いはない、とも言えそうですね。
やっぱり、WinとLinuxでメーラ関連を共通にしようとすると、
Wanderlust（あるいはMew）しかない感じかなぁ…