pingaの最初のパーティションには依然としてWin95が入っている。仕事に使ったりすることもあろうし、コントロールパネルでハードウェアの情報、I/OポートやIRQなどを見たいってのもあって、とりあえずは消さずに残っている。電源を入れたときにブートするのはLinuxのほうで、もうほとんどWin95をブートすることはないんだけどね。選択すれば、今でもWin95も立ち上がるようにはなっている。今回は、入手した3comの3C509Bをpingaに追加して、メビウス(こいつのホスト名は、実はpinguだ。pingaの兄貴ね。ややこしいのぅ)とEthernetで接続してみようと思っているのだが、こういうハードを追加して動作を見るような場合には、Win95が残っているとオレのようなLinuxのタコには都合がいいときもある。
特に、そのハードが新品でないもらい物だったりすると、そもそも動くものなのか、保証の限りではないので、黙ってスロットに差してWin95を立ち上げ、自動認識させてひと通りの動作確認をしたり、コントロールパネルで設定を確認するってのは常套手段なんじゃなかろうか。というわけで、サクッとpingaの空きISAスロットに3C509Bを差してWin95を立ち上げてみた。
あっけなく認識し、3C509Bが生きていることが分かった。やるなビル。こういうとこだけは見事なもんだ。ま、これでもう、pingaのWin95にはほとんど用はない。今すぐブッ飛んでお亡くなりになってもいいぞ。とはいえ、Linuxがどれくらいディスクを使っているかdfで見てみると、まだたったの66%だ。とりあえずディスクを増やす必要はないなぁ。それどころか、Win95の方がキュウキュウとしているぞ。MSVC++だのVisualCafeだのJDKだのと、いい気になってブチ込んでいたら、もう850MBも使ってやがる。あと150MBしかないじゃねぇか。
pingaのWin95のパーティションはただのVFATで、FAT32は使っていないので、ますます消費が激しく見えているってのもある。Linuxからでも、新しい2.1.x系のkernelを使えばFAT32やNTFSなんかのパーティションも見えるらしい(リードのみだったかな？)が、pingaのkernelは最新版とはいえ2.0.x系なので、ファイルの共有なんかの都合も考えてFAT32は避けたのだ。そもそもFAT32自体嫌いだ(というかロクなもんじゃないと思う)し、もともと1GBしか割り振らないつもりだったので、VFATをDriveSpace3で圧縮してやるなりしたほうが、かえって具合がいいだろうと思ったしね。
Linuxのkernel 2.0.33からは、圧縮されていないVFATは読み書きできる(つまりマウントできる)ので、普段は、必要に応じて/dosなどにマウントして使っていたのだが、まだ圧縮してはいなかった。で、例によってLinus-users-MLの過去ログやfj.os.linuxの過去ログ、JFのHOWTO類を漁ると、dmsdosfsというFATの圧縮ドライブをマウントできるドライバがあるということがわかったので、さっそくDMSDOS fs on LINUXからもらってくることにした。実際にもらってきたのはdmsdosfs-0.8.0a.tgzという、安定指向といわれているバージョンのものだ。ロングネーム対策パッチも、このページの管理者の方が作成して公開してくれている。これも忘れずにもってこよう。展開してみると、dmsdosfs-0.8.0.9というディレクトリができて、0.8.0aではない。なんだ、aじゃなくて9なの？１つ少ないなぁなどと思ったが、どうもこれでいいらしい。
DMSDOS.TXTを読むと、要するにkernelに対するpatchのようだ。2.0.x系のkernelでは、2.0.27までは動作確認されているらしい。安定指向ってのは早い話がちょっと古いってことなので、まぁしかたあるまい。2.0.33にうまくパッチがあたらなければ、サッパリとあきらめよう。というわけで、
patch -p0 < patch-dmsdos-0.8.0.a-lfn.txt などとして、まずはロングネーム対策パッチをあてる。これは当然問題なかった。で、pingaのkernelは2.0.33なので、rootになってINSTALL_2.0.1というシェル・スクリプトを実行する。
/usr/src/linuxの下の、kernelのソースにズラ〜ッとパッチが充てられていく様子が表示される。が、なにやら1箇所エラーになってしまった。あちゃ〜やっぱり…などと見ているうちに、make configが自動的に起動され、kernelの再構築まで突き進む気らしい。ちょちょちょっと待ってくれぃ。
慌てて^Cでmake configを中断させる。エラーになったのは、/usr/src/linux/fs/Makefileで、どうやら2.0.27の頃とはmakefileの書式が変わってしまって、書き換え対象の文字列自体が見つけられなかったようだ。2.0.27のソースは持っていないので確かめようもないが、Makefile.dpat_1.3.94というファイルがうまくあたらなかったパッチの中身なので、手であててやることにした。変更内容自体はたいしたことではなくて、make configでkernelを再構築する際に、ファイルシステムとしてdmsdosが選択できるようにする、というだけらしい。
これでとりあえず、make xconfigしてみた。オレってヤツはどうもヌルくて、make configがあまり好きぢゃない。もう決まりきっているオプションまでバカ正直に聞いてくれるし、かといってバリバリとキーを押して進んでいくと、うっかり変更したいオプションを通り越してしまったりする。しかも戻れないので^Cでやり直しだ。それに比べると、make xconfigは楽でいいね。変えたいオプションを直接選んでちょっと変えて保存して終りだもん。脱線したけど、make xconfigしてFilesystemsを見てみると、おぉ！たしかに
"dmsdos: compressed msdos filesystems support"という選択肢がそっと増えている。よ〜し、makeは行けそうだ。
ここでとっととmakeしてしまうのも慎重で結構なのだが、シクッたらFATの圧縮自体をあきらめちゃうハラはできてるので、さらに欲張ってもう一つパッチをあてることにする。vfatjpと呼ばれているヤツで、vfatのロングファイルネームに格納されているunicodeを、eucに変換するときに日本語の面倒を見てくれるらしい。もちろん双方向だろうから、eucで日本語のファイル名を付ければ、Win95上からも日本語で見えるに違いない。
まぁ個人的には、eucだろうがShift-JISだろうがunicodeだろうが、日本語を解さない人にとっては意味不明なのは変わらんわけだから、そもそも日本語のファイル名なんぞ付けること自体どうかしてると思う(某ソフト会社なんて1バイトのカナを好んで使ってるから脱力する)が、面白そうなので話の種にあててみることにする。実際に持ってきたのはlinux-vfatjp-patch.tgzで、ftp.win.or.jpから。さっそく展開してサクサクッとあててみたが、とくにエラーなどは見受けられなかった。
で、もう一度make xconfigして、追加した3C509Bのドライバが組み込まれているのを確認し、さらにCONFIG_FIREWALL、CONFIG_INET、CONFIG_IP_FORWARD、CONFIG_IP_FIREWALL、CONFIG_IP_FIREWALL_VERBOSE、CONFIG_IP_MASQUERADE、CONFIG_IP_MASQUERADE_ICMP、CONFIG_IP_ALWAYS_DEFRAGなどをYにした。IPマスカレードを使うつもりなんでね。でもって、ファイルシステムは、ext2をYにした以外はFAT、VFAT、ISO9660あたりの使いそうなヤツと、追加されたdmsdosはすべてMを選んでモジュールにした。で、とっととmake dep;make cleanして、make zliloで再構築してしまうことにする(笑)。コーヒー入れてる間にmakeは終るので、飲みながらmake modules;make modules_installしておしまい。
リブートして様子を見るが、とりあえず問題はなさそうだ。機能ダウンや不都合は見受けられない。shutdownしてWin95を立ち上げ、圧縮エージェントを起動する。ガラガラガラガラいつまでもやってるので、ほったらかして買物に行くことにする(笑)。
結局、DriveSpace3のHiPackを使ってWin95のパーティションは空き領域が600MB程度に増えた。こんだけありゃ余裕だな。どうせ今後はゲームくらいしか入れる予定もないし(笑)。で、mount -t vfat /dev/sda1 /dos としてマウントしてみると、うむ、確かに見えない。drvspace.000という馬鹿でかい1個のファイルに見えている。umountして今度は、mount -t dmsdos /dev/sda1 /dos としてマウントしてやると… おぉ！今度はdrvspace.000がディレクトリになっている！中も見えるぞ。ロングネームもバッチリだ。だか常に/dos/drvspace.000から入っていくのはちょっと面倒なので、ln -s /dos/drvspace.000 /compとして、マウントした後は/compがWin95のドライブに見えるようにしてやった。
また、圧縮での書き込みは死ぬ程遅く、やっぱりなんか失敗しちまったのか！と疑ったほどなので、comp=noというオプションをつけてマウントし、書き込み時には圧縮しないようにした。で結局 /etc/fstab に
/dev/sda1 /dos dmsdos user,rw,comp=no,long=on,vfat 1 1などと追加しておいた。これでわざわざrootになったり、sudoしなくても、いつでも好きなときにmount /dosとするだけでマウントでき、あとは/comp経由で自由に読み書きできる。
で、お楽しみの日本語ファイル名だが、結論として、圧縮ドライブの中の日本語ファイル名は読むことはできていない。???????.????などのように、すべて?マークになってしまうのだ。vfatjpがうまくあたってないのか確かめてみたが、どうもうまくあたっているようだ。ソースが一式あるのだから、追いかけて動きを見てやろうかとも思ったが、kernelのデバッグのやり方を知らない(笑)ので、とりあえず切り分けだけでもするために、Win95でフォーマット済みのZIPドライブをvfatでマウントし、日本語のロングファイル名を付けてみた。
「今日もオラオラ状態だ.bmp」などというフザけたファイル名でZIPドライブにファイルを作ると、こっちはちゃんと読めるし、Win95からも同じファイル名に見えるようだ。詳しくソースを見ていないからなんともいえないが、恐らくdmsdosがvfatのロングファイルネームを持ってくるときに、8ビット目が立ってるヤツは片っ端から?にしているのではなかろうか。vfatjpであてたパッチの部分に渡ってきたときには、すでにファイル名は?になってしまっているっぽい。まぁオレ的には日本語ファイル名など使うことはないし、圧縮されていないvfatの日本語ファイル名は確かに扱えているようだから、それなりに話の種にはなったわけで、当初の目標を達成？したとしておこう。
あ、あともう一つ不可解なこととして、dfの結果がおかしいってのもある。いや、こういう仕様で、FAQなどを隅々まで読めば書いてあるのかもしれないが… とにかく、dfで圧縮ドライブを見ると、Capacityが100%と言われちゃうんだよね。だけど書き込めるんだよ(笑)。で、du -cS /dos とやってduで/dos以下を全部なめてやると、total 850560などとなって、840MB前後ってことで、これはWin95から見たときとほぼ等しい。まぁ当然といえば当然だけど、個々のファイルの大きさも正当なものだ。うむ〜。
えらく長々と書いてしまった。次はIPマスカレード、と行きたいところだが、その前にちょっとだけ、まだ触れていないユーティリティについて書いておこう。便利だし、お世話になってるしね。
| メール | 前へ | 次へ | 戻る |