sys_tz.tz_minuteswest が 0 になってしまうのは、玄箱の RTC が UTC で動いているからではなく、玄箱では hwclock が動かないためのようである。hwclock のソース（util-linux パッケージ内）を見たところ、hwclock がちゃんと動いていれば、sys_tz.tz_minuteswest は正しい値にセットされるようである。試しに、settimeofday() を呼び出して、sys_tz.tz_minuteswest を正しい値にセットするプログラムを書き、それを実行してから、mount -t vfat で MO をマウントしてみたところ、タイムスタンプが９時間ずれるのは解消された。起動時に、hwclock の代わりに、settimeofday() を呼んでタイムゾーンだけをセットするプログラムを実行させるようにしておけば良さそうである。わざわざカーネルモジュールを作ったのは、無駄になってしまったようだ。
プログラムはこんな感じ。
#include <stdio.h>
#include <time.h>
#include <sys/time.h>
int main(int argc, char *argv[])
{
struct timezone tz = {0, 0};
tzset();
settimeofday(NULL, &tz);
tz.tz_minuteswest = timezone / 60;
settimeofday(NULL, &tz);
return 0;
}
settimeofday() には、Linux 特有の事情があるので念のため２回に分けて呼び出すようにしてある。
あとは、このプログラムを実行するためのスクリプトを /etc/init.d/ に置いて、
# update-rc.d scriptname defaults 50
などとしておけばよさそう。
「複数 USB ドライブの検証」によると、玄箱/HG で複数の USB ドライブを接続して同時にアクセスすると、ファイルが破損するらしい。256MB の USB メモリと、540MB の MO を玄箱につなぎ、USB メモリから MO に 110MB ほどのデータ（ファイル数 約8,500）をコピーしてみた。１回目、見事に MO のデータが破損。ファイル名のおかしなディレクトリができたり、クラスタチェーンが発生したりした。dosfsck では直らず、フォーマットし直した。そのあと２回同じことを試してみたが、今度は全く問題は発生しなかった。もう少し詳しい検証をする必要がありそうだが、同時アクセスはやめておいた方が無難なのかもしれない。
SyncHack - Mc.N Homepage SDK の Wiki ページ。HDD/term/SCSI 等の各種資料へのリンクなど。
もうちょっと調査。640MB の MO を mkdosfs でフォーマットしたときの挙動が怪しい気がする。-F を使わずに以下のように実行すると、
# mkdosfs -Iv -S 2048 /dev/sda mkdosfs 2.11 (12 Mar 2005) Auto-selecting FAT32 for large filesystem mkdosfs: Attempting to create a too large file system
とエラーが出る。-s を指定せずに FAT32 でフォーマットしてもやはりおかしい。
# mkdosfs -Iv -S 2048 -F32 /dev/sda mkdosfs 2.11 (12 Mar 2005) /dev/sda has 20 heads and 61 sectors per track, logical sector size is 2048, using 0xf8 media descriptor, with 310352 sectors; file system has 2 32-bit FATs and 8 sectors per cluster. FAT size is 76 sectors, and provides 38771 clusters. Volume ID is 43b2ba03, no volume label.
FAT32 は、クラスタ数が 65526 以上と決まっているのに、クラスタ数が 38771 と表示されている。クラスタ当たりのセクタ数を 4 以下にすればまともにフォーマットされる。
# mkdosfs -Iv -S 2048 -F32 -s4 /dev/sda mkdosfs 2.11 (12 Mar 2005) /dev/sda has 20 heads and 61 sectors per track, logical sector size is 2048, using 0xf8 media descriptor, with 310352 sectors; file system has 2 32-bit FATs and 4 sectors per cluster. FAT size is 152 sectors, and provides 77504 clusters. Volume ID is 43b2b9f3, no volume label.
MO にボリュームラベルを設定する方法も調べてみた。mkdosfs でフォーマットするときには、-n でラベルを指定すればよい。一方、フォーマット後にラベルを設定する場合には、mtools の mlabel コマンドを使えば良さそうである。apt-get で mtools をインストールしてから、/etc/mtools.conf でドライブ名の設定をして、mdir コマンドを使ってみたところ、
Total number of sectors not a multiple of sectors per track! Add mtools_skip_check=1 to your .mtoolsrc file to skip this test
というエラーが出た。とりあえず、/etc/mtools.conf に MTOOLS_SKIP_CHECK=1 という行を書き加えておいたところ、mdir が動いた。mlabel も問題なく使えた。mtools が FAT32 でも使えるのかが少し心配だったが、mlabel は特に問題ないようだった。mdir は FAT32 ではタイムスタンプが正しく表示されていなかった。
玄箱/HG で mount -t vfat でマウントすると、タイムスタンプが UTC として扱われて９時間ずれてしまうことに気付いた。つまり、玄箱で USB メモリや MO に書き込んで、それを Windows へ持って行くとタイムスタンプが９時間遅れてしまう。これは非常に重大な問題だ。
少し調べてみると、XvFat という vfat に対する拡張が見つかったが、カーネル 2.4.x 用で玄箱には使えない。
Kernel_source - LinkStation から玄箱のカーネルソースを取ってきて、９時間ずれる原因を探ってみた。fs/fat/misc.c に Unix の日時と、FAT の日時を変換している部分があった。一応、
secs += sys_tz.tz_minuteswest*60; unix_date -= sys_tz.tz_minuteswest*60;
という感じで、UTC とローカル時刻を変換している部分はあるようなのだが、機能していない。gettimeofday() を呼び出すテストプログラムを書いて、タイムゾーンを調べてみたところ、sys_tz.tz_minuteswest は 0 になっていた。システムクロックが UTC で動いている場合には、sys_tz.tz_minuteswest == 0 になってしまうようである。
玄箱のシステムクロックをローカルタイムで動かすことができるか調べてみた。Debian では /etc/default/rcS に UTC=no と書いておけば、システムクロックがローカルタイムで動いているとして扱われる。しかし、そのようにしても玄箱のシステムクロックは、UTC のままだった。調べてみると、システムクロックを UTC とするか、ローカルタイムとするかの設定は hwclock コマンドを使って行われるようになっていた。しかし、玄箱では hwclock が動かないためにうまくいかないようだ。
玄箱で hwclock が動かないのは、drivers/char/mel_rtc.c の mel_rtc_ioctl() で常にエラーを返しているのが原因のようだ。
fs/fat/misc.c の日時変換部分を JST 専用に改造して、カーネルモジュールにしてみたらどうだろうと思い、試してみた。
Kernel_source - LinkStation から 2004.7.29 版のソースを取ってきて、カーネルコンパイル - Debianハックしちゃうぞ、拡張設定 / カーネルの変更:[玄箱] などを参考に、
$ make hdhglan_config $ make oldconfig $ make menuconfig (あるいは vi .config としてカスタマイズ) $ make dep $ make CC=gcc-2.95 modules
としてモジュールをコンパイル。gcc 3.3 では、コンパイル途中でエラーが出るモジュールがあるので、最後の CC=gcc-2.95 の指定が必要となる。改造版 fat.o を作って、insmod コマンドでロードしてみたが、mount -t vfat ではカーネルに組み込み済みの部分が使用されて、改造版 fat.o は使用されなかった。カーネルモジュールを組み込み済みモジュールよりも優先して使用する方法はないものだろうか。
vfat.o と fat.o を１つのモジュールに統合して、vfat 以外の何か別のファイルシステム名で呼び出せるようにしてしまえばいいのではないかと思い、試してみることにした。とりあえず vfat の JST 専用版ということで、vfatj という名前にしてみた。
$ mkdir fs/vfatj $ cp -p fs/vfat/Makefile fs/vfatj/ $ cp -p fs/vfat/*.c fs/vfatj/ $ cp -p fs/fat/*.c fs/vfatj/ $ patch -p0 -T < vfatj.diff $ make hdhglan_config $ make oldconfig
としてから、.config に CONFIG_VFATJ_FS=m という行を追加して、
$ make dep $ make CC=gcc-2.95 modules
としてモジュールをコンパイル。
$ su # mkdir /lib/modules/2.4.17_mvl21/kernel/fs/vfatj/ # cp -p fs/vfatj/vfatj.o /lib/modules/2.4.17_mvl21/kernel/fs/vfatj/ # chown root:root /lib/modules/2.4.17_mvl21/kernel/fs/vfatj/vfatj.o
としてモジュールをインストールして、/etc/modules に vfatj と書いた行を追加してから再起動。
# mount -t vfatj -o umask=0 /dev/sda /mnt/mo
としてマウントしたところ、タイムスタンプが９時間ずれる問題は一応解消された。
SpringM は、L コマンドでディレクトリを移動すると、ディレクトリ名を全て大文字に変換してから移動する。例えば C:\Program Files に移動しようとしたら、実際には、C:\PROGRAM FILES に移動することになる。Windows 上だけで使っているのならばこの仕様でもあまり問題はないのだが、Cygwin が絡んでくると問題が出てくることがある。以前から気になっていたので対策してみることにした。/etc/profile の CHERE_INVOKING のあたりを、
# Make sure we start in home unless invoked by CHERE
if [ ! -z "${CHERE_INVOKING}" ]; then
unset CHERE_INVOKING
cd "`cygpath -u \"\`cygpath -alw .\`\"`"
else
cd "${HOME}"
fi
というように変更してみた。cygpath -alw . でカレントディレクトリ名を大文字小文字の正しい Windows 形式のフルパスに変換し、cygpath -u で Unix 形式に戻して、そこへ cd している。これで SpringM から Cygwin を起動しても、カレントディレクトリ名が全て大文字になってしまうことはなくなる。
murasaki を入れたときに、依存関係の都合で libc6/testing を入れたのだが、apt-get upgrade を実行した際に、勝手に libc6/unstable にバージョンアップしてしまっていた。「AptGet - Debian GNU/Linux スレッドテンプレ」の「testing や unstable のパッケージを借りたい」によると、/etc/apt/apt.conf.d/99target に
APT::Default-Release "stable";
と書いておくよりも、/etc/apt/preferences に
Package: * Pin: release a=testing Pin-Priority: 105 Package: * Pin: release a=testing-proposed-updates Pin-Priority: 110 Package: * Pin: release a=unstable Pin-Priority: 90
と書いておく方が良いようだ。早速これを試してみたところ、testing から unstable に勝手にバージョンアップされることはなくなった。
mkdosfs を使って MO のフォーマットを行ってみた。（mkdosfs のバージョンは 2.11 (12 Mar 2005)） -c オプションを指定しなければ自動的にクイックフォーマットされるようである。1〜2秒程度でフォーマットが終わり、手持ちの Windows 用のフォーマッタよりも早かった。
いくつかパラメータを変えて動作を試し、df で容量も調べてみた。
1.3GB - WinXP (FAT16) Filesystem 1K-ブロック 使用 使用可 使用% マウント位置 /dev/sda 1211520 0 1211520 0% /mnt/usbdisk 1.3GB - mkdosfs -I -S 2048 /dev/sda (FAT32) /dev/sda 1211024 16 1211008 1% /mnt/usbdisk 1.3GB - mkdosfs -I -S 2048 -F 16 /dev/sda (FAT16) /dev/sda 1211520 0 1211520 0% /mnt/usbdisk 640MB - mkdosfs -I -S 2048 -F 16 /dev/sda (FAT16) /dev/sda 620528 0 620528 0% /mnt/usbdisk 540MB - mkdosfs -I /dev/sda (FAT16) /dev/sda 520472 0 520472 0% /mnt/usbdisk
まず、スーパーフロッピーフォーマットにするためには -I の指定が必須である。1.3GB と 640MB の場合は、-S 2048 としてセクタサイズを明示しないといけなかった。FAT 種別を指定しない場合には、1.3GB は FAT32 になり、640MB はエラー、540MB は FAT16 になった。「Linux Tips - MOのディスクをフォーマットするには」では、-s でクラスタサイズを指定しているが、特別な理由がない限り指定しない方が良いように思われる。-v を指定するとどういうパラメータでフォーマットされたか詳しく表示される。
バグらしき挙動を発見。-S 2048 にした状態でも、-s 128 という指定が可能。これだとクラスタサイズが 256KB になってしまい、おそらく Win9x ではアクセスできない。NT 系ではアクセスできるかもしれないが、やめておいた方が無難だろう。
引き続き Linux で MO をフォーマットする方法を調べてみた。mei が Linux にも暫定対応しているようだ。しかし、mei のソースを見ると、GIGAMO には対応していないようだ。やはり、おとなしく mkdosfs を使うのが良いのだろうか。
ちなみに、作者のサイト (euc.JP: tech docs, BeOS tools) にはいろいろ興味深い情報がある。
mei のドキュメントを見て、MO の規格書が Ecma Standards で公開されていることを知った。(128MB, 230MB, 385MB, 1.3GB, 2.3GB) 640MB の規格は ECMA にはない。ISO では ISO/IEC 15041:1997 という規格になっているが、ISO の規格書はただでは入手できないのが残念である。ドラフトなども探してみたが見つからなかった。
/var/log/daemon.log を見ると、
ntpd_initres[333]: server returns a permission denied error
というエラーが大量に残っている。エラーメッセージでググってみたところ、chmod 666 ntp.drift とすればよいというものが見つかったが、関係なかった。よく調べてみると、設定をミスって ntpd が２重起動していたのが原因だったようだ。
ところで、玄箱/HG で ntpd を動かしていると、どういうわけか１日に１回、synchronization lost が発生するのだが、何なのだろう。以前から不思議に思っているのだが、未だに原因が分からない。
玄箱/HG と USB2-SC2 をつなぐ USB ケーブルを、千石電商で買ってきた光る USB ケーブルに交換してみた。なかなか怪しげでおもしろいが、もう少し暗くてもよいかもしれない。
コマンドラインから MO をイジェクトできるようにしてみようと思った。とりあえず apt-get で eject をインストールしてみた。MO で使えるとは明記されていなかったが、eject /dev/sda とすることで MO がイジェクトできた。
「LinuxでのSCSIデバイス名を予測可能なものにする：scsidev」というページを見つけたので、試してみた。apt^get install scsitools として scsidev 等をインストールして、/etc/scsi.alias を書いてから、scsidev を実行してみたところ、
Linux kernel reports new device type "Optical-Device". Mail author! Low level dev without HL driver? Low level dev without HL driver? Unable to match device for line 1 (alias mo)
というエラーが出た。１行目を見ると、scsidev は MO には対応していないように思える。scsidev utility for Linux から Ver.2.35 のソースをダウンロードして見てみると、"Optical-Device" となっているべきところが、"Optical Device" と書かれていた。バイナリエディタで、/sbin/scsidev を開いて、"Optical Device" を "Optical-Device" に書き換えてみたところ、１行目のメッセージは出なくなった。しかし、相変わらず残りのエラーが出て、デバイスファイルが作成されない。ソースを見ると、/proc/scsi/scsi の中の
Attached drivers:
で始まる行から、ドライバ名を取得しているようなのだが、玄箱/HG の /proc/scsi/scsi を見てもそれに該当する行が見あたらない。どうやら 玄箱/HG では scsidev はうまく動かないように思われる。
結局、USB 機器をつなぐ順番によって、デバイスファイル名がころころ変わる問題にはどのように対処したらよいのだろうか。
USB-IDE 変換ケーブルに付属の AC アダプタ用の電源ケーブルを改造。どこの国のか、よく分からないごついプラグを切り落として、日本用の AC プラグに交換して、ついでに電源スイッチも取り付けてみた。
もう一度、玄箱/HG + FMO-1300USB を試してみたら、FMO-1300USB 付属の変換ケーブルで問題なくマウントできた。せっかく USB2-SC2 を買ったというのに・・・。単に接続が悪かっただけなのか？
このままでは玄箱で MO がフォーマットできないことに気付いて、少し調べてみた。Linux Tips - MOのディスクをフォーマットするにはというものが見つかった。この方法を使うには、/sbin/mkfs.msdos が必要なようなのだが、それが見あたらない。
# apt-get install dosfstools
とすることで、/sbin/mkfs.msdos がインストールされた。これで、mkfs -t msdos、mkfs -t vfat、あるいは mkdosfs で MS-DOS フォーマットができるようだ。ところで、クイックフォーマットはできるのだろうか。手持ちの Windows 用のフォーマッタならば 10秒でフォーマットできるのだが、mkdosfs だとどれだけ掛かるのだろう。
昨日買った USB-IDE 変換ケーブルを直してみた。2.54mm ピッチの方のコネクタを一度外して、まともな位置に取り付け直したところ、ケースが斜めになっているのが直った。早速、余っている DVD ドライブを接続してみたが、ドライブ名が化けて、CD-ROM も読み込めない。化け方を見ると、bit 12 がおかしくなっているようだ。半田付け部分を確認してみると、bit 12 が接続されていなかった。ちゃんと半田を付け直したところ、無事に使えるようになった。
久しぶりに神保町へ行ってみた。「Visual C++ プログラマのための COM 入門」を \1,500 で購入。デバイスドライバ関係の本もいくつかあって非常に気になったのだが、やめておいた。
次は秋葉へ。PC-Success の跡地に新しい店が入っていた。USB2.0-IDE 変換ケーブルが \980 で売られていたので買ってみた。電源ケーブルが日本向けではないために安くなっていたようだ。普通のめがねケーブルを使えばよいようなので問題はないだろう。最後にヨドバシで、I-O DATA の USB2-SC2 を購入。USB2.0-SCSI 変換ケーブルは各社から出ているが、USB2-SC2 が一番小さいのでこれを選んだ。
早速、玄箱/HG に USB2-SC2 を使って FMO-1300USB をつなげてみた。最初は FMO-1300USB に付属の変換ケーブルを使ったときと同じようにマウントできなくて焦ったのだが、MO ドライブと USB2-SC2 をつなぎ直したりしたところ、無事マウントできるようになった。
\980 で買った USB-IDE 変換ケーブル (R-DriverII) の箱を開けて驚いた。IDE コネクタが斜めになっている。これだと 2.5inch HDD がちゃんと挿さらなさそうである。どうせ安物だからということで、コネクタ部分のケースを開けてみたらさらに驚いた。半田付けが実に汚い。チップ部品も手半田のようだ。コネクタが斜めになっている原因だが、どうやら基板の裁断ミスのようだ。基板の角が切り落とされて、ケースの中で引っかからなくなってしまい、コネクタが斜めになってしまうようだ。コネクタの取り付け位置も微妙にずれている。これぞ支那製(?)の本領発揮か？ さてどうしたものだろう。
Linux Tips - MOを使うには
Linux Tips - CD-ROMを自動的にマウントするには
Linux Tips - 全ユーザーがCD-ROMをアンマウントできるようにするには
玄箱/HG で murasaki の挙動が怪しかったのは、玄箱うぉううぉう♪の Debian 化キットをそのまま使ったことに問題があったようである。玄箱うぉううぉう♪の Debian 化キットは、中に入っているカーネルモジュールが玄箱用で玄箱/HG 用ではないために問題が発生していたようである。/var/log/daemon.log を見ると、カーネルモジュールのバージョンが合っていないとのエラーが出ていた。
まずは、カーネルモジュールのバージョンを一致させるために、玄箱用のカーネルモジュールである、/lib/modules/2.4.17_kuro-box/ と /lib/modules/extra/ を全て削除して、代わりに元の玄箱/HG のイメージから、/lib/modules/2.4.17_mvl21/ を復元してから再起動した。
ここで、/etc/murasaki/scripts/auto_setup を実行してみると、出力結果は空となった。/etc/murasaki/murasaki.preload を空にしておいたのは間違いではなかったようである。
次に、/etc/murasaki/murasaki.conf は、init.usb: と usb: だけを on にして、残りは全て off にした。/etc/murasaki/murasaki.call は、[usb]: usbdisk の行を削除して、代わりに usb-storage: usbdisk と書いておいた。usb-storage の部分は [] で囲まないのがポイントである。/etc/murasaki/scripts/usbdisk はおとといのままである。仕上げに、設定ファイルを再読込するために、/etc/init.d/murasaki restart を実行して完了。
これで、USB メモリを挿すと自動的に、/mnt/usbdisk/ にマウントされるようになり、おとといのように、mount コマンドが複数回実行されるということもなくなった。
日本語の扱いがどうなっているか、まだ確認してないが、/etc/fstab に、
/dev/sda1 /mnt/usbdisk vfat user,rw,noauto,codepage=932,iocharset=euc-jp,umask=0 0 0
といった感じで、codepage と iocharset を設定しておけばよいようだ。
掲示板で指摘があったので、SCSI ID を 0 に設定して再度試してみた。WinXP では、OS の標準のドライバで無事アクセスできるようになった。しかし、玄箱/HG で使ってみようとしたところ、相変わらず mount コマンドで、「メディアが見つかりません」というエラーが表示されてマウントできない。残念。
「玄箱で遊ぼう!!」などを見ながら、murasaki の設定を行ってみたが、なかなかうまく動いてくれない。試しに、玄箱/HG のオリジナルイメージから murasaki の 旧バージョンを取り出して試してみたところ、「玄箱で遊ぼう!!」に載っているやり方でそのまま動いた。
apt-get でインストールした murasaki 0.8.11-3 でも設定次第で何とかなるのではないかと思い、もう少し試してみた。/etc/murasaki/murasaki.preload の中身を空にしてみたところ、ようやく動くようになった。
残りの設定の詳細だが、まず、/etc/init.d/murasaki の中に /etc/murasaki/bin/auto_setup となっている部分があるが、/etc/murasaki/scripts/auto_setup に修正した。が、これはあまり関係ない。あとは、/etc/murasaki/murasaki.call, /etc/murasaki/murasaki.conf, /etc/murasaki/scripts/usbdisk を修正。
これで一応動くようになったが、USB メモリを挿すと mount コマンドが４回も実行されるのが気になるところである。
参考 URL
玄箱で MO を使えるようにしてみたいと思い、試してみた。FMO-1300USB を、付属の USB-SCSI 変換ケーブルを使って玄箱につないでみたが動かない。/proc/scsi/scsi を見ると、一応ドライブ名は認識している。一方 /proc/bus/usb/device を見ると、変換ケーブルは、Class: 08, SubClass: 06, Port: 50 の普通の USB マスストレージクラスのようである。/proc/scsi/usb-storage-1/1 を見ると、変換ケーブルの製品名等も確認できた。しかし、mount コマンドを使ってマウントしてみようとすると、「メディアが見つかりません」と表示されてマウントできない。
FMO-1300USB を Let's Note につないでみたところ、ドライバが見つからず使えなかった。WinXP ならば、USB マスストレージクラスならば標準のドライバで使えるはずだと思うのだが・・・。よく分からないので、変換ケーブルが古すぎて規格に正しく対応していないのだろうと決めつけて、諦めることにした。
USB 2.0 対応の USB-SCSI 変換ケーブルが１本欲しいところだが、高いので困る。
APT HOWTO - インストール済パッケージを特定バージョンのまま保持する方法 など
APT と dpkg の使い方
玄箱内部でのメールの配送に Exim を使っているのだが、以前から failed to open DB file /var/spool/exim/db/wait-remote_smtp という内容のエラーメールが送られてくるのが気になっていた。調べてみたところ、雑記ばらん - [Linux] failed to open DB file /var/spool/exim/db/retry: File exists という記事を発見。以下の作業でエラーはなくなった模様。
# apt-get install libdb3-util # cd /var/spool/exim/db # /etc/init.d/exim stop # db3_upgrade retry # db3_upgrade wait-remote_smtp # rm *.lockfile # /usr/sbin/exim_tidydb /var/spool/exim retry # /usr/sbin/exim_tidydb /var/spool/exim wait-remote_smtp # chown mail:mail * # /etc/init.d/exim start
Debian (Sarge) 化してある玄箱/HG で、USB メモリをホットプラグで使いたいと思い調べてみた。こういう場合には murasaki を使うのが一般的なようだが、apt-get install murasaki としても、murasaki は stable パッケージではないためインストールされなかった。「Debian “stable”における“testing”及び“unstable”パッケージの導入方法」を見て unstable をインストールできるように設定してから、以下のコマンドを実行した。
# apt-get install libc6/testing # apt-get install libc6-dev/testing # apt-get install locales/testing # apt-get install libncurses5/testing # apt-get install libncurses5-dev/testing # apt-get install murasaki/unstable
murasaki/unstable が libc6/testing に依存していたために、いくつかのパッケージをインストールし直すことになった。murasaki の設定はまだ行っていない。
CPAN を使うには、
> perl -MCPAN -e shell
とする。初回起動時には設定画面が出る。CPAN の再設定を行うには、
> perl -MCPAN::FirstTime -e CPAN::FirstTime::init
とする。あるいは、cpan のプロンプトから、
cpan> o conf init
とする。（あるいは、C:\Perl\lib\CPAN\Config.pm を削除。）
VS2005 Express 日本語版が公開されたのでダウンロードしてみた。
結局、Term::ReadPasswd の配布用パッケージを作ってしまった。ActivePerl 5.8.x ならば、以下のコマンドでインストールできる。
> ppm install http://homepage3.nifty.com/k-takata/mysoft/Term-ReadPasswd.ppd
紹介ページの作成はまたあとで。
Perl でメッセージボックスを表示するには、
use Tk; $top = MainWindow->new; $top->withdraw; # メインウィンドウを隠す $top->messageBox(-title => "title", -message => "message");
あるいは、Windows ならば、
use Win32;
Win32::MsgBox("message", 0 | MB_ICONINFORMATION, "title");
とすればよい。Tk を使う場合には、アイコンを無しにすることはできないようだ。
JDK 5.0 Update 6 をインストールしたのだが、インストール後に C:\Documents and Settings\(user)\Local Settings\Application Data\{32A3A4F2-B792-11D6-A78A-00B0D0150060}\J2SE Development Kit 5.0 Update 6.msi という名前の 60MB 近いサイズのファイルが残された。最近のバージョンではこのようになっているようだが、一体なぜこんなファイルが残されるのか、非常に不思議だ。
ActivePerl を使って、コンソール上でパスワードの入力をさせたかったのだが、良い方法がない。Unix 系ならば Term::ReadPassword というものがあるのだが、内部で使っている Term::ReadKey が ActivePerl では動かないということもあって、残念ながら使えない。ActivePerl では、エコーバックしない文字入力として、Term::Getch というものもあるが、キーが押されたときではなくキーが離されたときに入力を返してきたり、Ctrl, Shift, Alt などの特殊キーにも反応するというかなり変わった仕様のため、はっきり言って使えない。しかも、Term::Getch が読んでいるのは標準入力なので、リダイレクトすることができてしまうというのも困った点である。仕方がないので、Term::ReadPassword と Term::Getch を参考にしながら、ActivePerl でも使える Term::ReadPassword もどきを書いてみた。名付けて Term::ReadPasswd。（てきとー） ActivelPerl 以外では Term::ReadPassword に対するラッパーとして機能するように書いたはずだが、確認はしていない。気が向いたら公開するかもしれないが、公開できるように体裁を整えるのはかなり面倒そうだ。
SMK の作者や、jFD2 の作者と間違えられても困るのだが・・・。
ActivePerl に Crypt::SSLeay を入れて、LWP を使って https://〜 にアクセスすると、タイムアウトが無視されてしまうようだ。指定したタイムアウト値に関わらず、サーバーから 20秒ほど応答がないと、
500 Connect failed: connect: Unknown error; Unknown error
というエラーになってしまう。Crypt::SSLeay のタイムアウトに関係のありそうな部分をいじってみたりしたが結局うまくいかなかった。
もう少し調査。Net::SSL::connect line 101 → IO::Socket::INET::connect line 224 → IO::Socket::connect line 114 → connect と順に呼び出されて、ここで上記のエラーが発生していた。
perl に -d を付けて起動するとデバッガが使える。s で次の命令、n で次の行、p で変数の値を表示、b でブレークポイントの設定、c で指定した場所まで実行、T でスタックトレースの表示等が使える。まだロードされていないサブルーチンにブレークポイントを設定するには、b postpone Net::SSL::connect というように b postpone を使えばよい。
ActivePerl には wperl.exe という、非コンソール型の実行ファイルがある。Perl/Tk を使ったりしていて、コンソールを開きたくない場合には perl.exe の代わりに wperl.exe を使うと良い。ActivePerl をインストールすると、.pl が perl.exe に関連付けられるが、wperl.exe には特に関連付けは行われないらしい。そこで、.plw を wperl.exe に関連付けしておくことにした。ちなみに、.wpl は WMP9 のプレイリストファイルだそうだ。
某所でバイナリエディタの Stirling に対するパッチが発表されていたので、読めなくなる前にメモしておく。（Stirling はあまり使っていないが。）
バイナリエディタについて http://pc7.2ch.net/test/read.cgi/software/997199775/ 915 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2005/12/09(金) 21:47:07 ID:dwxLLdFp0 主にTTFファイルをバイナリエディタで編集している このスレ的にもおそらく激しくマイノリティな俺ですが。 Stirling 1.31で+方向のオフセット移動が出来ないバグがあって不便だったので Stirling.exe自体を解析して修正しました。 せっかくなので差分を晒しておきます。 01851F:E0 -> F0 018540:E0 -> F0 01854E:E0 -> F0 917 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2005/12/10(土) 16:38:46 ID:bpgkTotj0 +方向のオフセット移動がわからない 918 名前：名無しさん＠お腹いっぱい。[sage] 投稿日：2005/12/11(日) 14:54:45 ID:M9mB6zi50 >>917 「指定アドレスに移動」機能では「2000」と入れて0x2000バイト目に飛べるほかに 「+10」や「-10」と入れることで現在のカーソル位置から0x10バイト先or前に 飛ぶことが出来る、はずなんだが、 実際に使ってみると、-10で0x10バイト前にはちゃんと飛べるが +10だと最初から10バイト目に行ってしまう（「10」と入れた場合と同じ）
久しぶりに MPLAB (v7.20) をダウンロードしてみた。MPLAB v6 の頃は VC6 のデバッグビルドになっており、再配布禁止のはずの msvcrtd.dll 等のデバッグ用ライブラリも同梱されていたが、v7.20 はちゃんと VC7.1 のリリースビルドでコンパイルされていた。
KEI-CQLEDSW にある回路図を見ながら、ByteBlasterII 互換ケーブルを作ってみた。ByteBlasterII 互換ケーブルは、以前にも書いたように、ByteBlaster2ダウンロードケーブルの製作にもあるが、こちらはパラレルポートが 36pin コネクタになっており、25pin コネクタ用の結線を調べるのが面倒だったのでやめておいた。回路自体はどちらもほとんど同じで、違いは、抵抗の付け方に一部違うところがある程度のようだ。どちらもパラレルポートの 9pin と 12pin をショートしてあるが、ByteBlaster II のブロック図を見ても、そこはショートしていないのだがなぜだろう。なお、このブロック図をそのまま作ろうとしたら、14pin でバッファを５個制御しているのが問題になっしまう。（74xx244 は４個単位で制御するため。） これをトランジスタを使ってうまく解決したのが、前述の回路ということのようだ。
レベル変換用の３ステートバッファとして、前述のサイトでは、低電圧向けの 74LCX244 や 74LV244 を使っているが、手持ちにはなかったので、代わりに 74VHC244 を使っておいた。
I/O 電圧が 3.3V のシステムで JTAG モード、Active Serial Programming モードの両方で書き込みができることを確認した。I/O 電圧が 2.5V や 1.5V だとやはり書き込めないのだろうか。ちょっと気になるところである。
そういえば、以前は ByteBlasterMV の回路は公開されていたのだが、現在公開されている ByteBlasterMV のデータシートからは、回路図が削除されてしまっている。（日本アルテラの方にはまだ回路図の載っている古いデータシートが残っているようだ。）
shobon-JTAG - com.miolab.junk.test
Tabbrowser Extensions を適当にいじってみたら、Mozilla で新しいウィンドウが開いて閉じてから新しいタブが開くという挙動が解消された。globalOverlay.js の 4000行目付近の openTabInsteadSelfInternal() を Ver.1.14.2005060301 の内容に戻してみたところ、Mozilla でもすぐに新しいタブが開くようになった。（tbe_mozilla_newwindow.diff）
SpringM のパッチがいくつかのブログで紹介されているのを発見。
PortForwarder の 2.6.0 をインストール。以前と同じように改造してみた。たぶん、ソースをいじってから自分でコンパイルするよりも、直接パッチを当ててしまった方が早い。
FILENAME PortForwarder.exe 00013D5C: 01 00 ; push 00000124 -> push 00000024
Tabbrowser Extensions でソースを新しいタブで開く設定にすると、chrome://navigator/content/viewSource.xul?url=〜 という形式でソースが表示されるのが以前から気になっていた。viewSource.xul を使うと、タブの中にメニューが表示されるのだが、そのメニューを使うことはほとんどない。view-source:〜 形式で表示すれば表示が速くなるのではないかと思い試してみた。また、ロケーションバーで view-source:〜 と入力した場合にわざわざ新しいタブで開くのも邪魔な気がするので、そのまま現在のタブに表示するようにしてみた。
試した結果、ソース表示の動作がかなり速くなった。しばらくこのまま使ってみようと思う。（tbe_view-source.diff）
選択した部分のソースを表示する場合には、どうしても viewPartialSource.xul を使わないといけないようなのでこれはそのまま残しておいた。
Mozilla 1.7.12 + TbE 2.0.2005113001 を使っても、相変わらず Mozilla では、外部アプリケーションから Web ページを開く際に、一度新しいウィンドウが開いてそれが閉じてから、ようやく新しいタブで表示されるという不思議な挙動が直っていない。かなり前に掲示板に報告したときは、完全に無視された。また、これが関連しているのか、ページの読み込み中にそのページが JavaScript で新しいウィンドウを開くと、今度はポップアップを許可しているにも関わらず、そのウィンドウが自動的に閉じて、新しいタブでそれが表示されてしまう。もう１回ぐらい報告してみるか。
ハングアップの日々に Google を使ったサイト内検索を付けてみた。これを付ける際に少し調べた範囲では、Google の site:〜 はドメイン名しか指定できないようなことが書かれているサイトが多い。Google 本家にはディレクトリ名を含めて良いかについては何とも書かれていないが、実際にはディレクトリ名を含めてもちゃんと動作しているようなので問題ないだろう。
検索用のフォームにはアクセスキーを付けてみた。最近のブラウザなら、Alt + アルファベット でちゃんとフォーカスが移動してくれるので、キーボード主体で見るには非常に便利だ。
サイト内検索を付けたせいで、自分の持っている携帯ではハングアップの日々が表示されなくなってしまったが、さすがに何年も前の携帯を使ってまでこのページを見に来るような奇特な人はいないだろう。
SMK で「救急フォルダに拡張子 .eml で保存」を実行すると、そのメールは OE 等で読めるようになるが、Mozilla Mailer では .eml は読めない。また、文字コードがヘッダでの指定に関わらず、全て Shift_JIS に変換されてしまっているので、メールとして正しい形式ではない。SMK のはき出した .eml を Mozilla Mailer 等で扱える mbox 形式に変換するスクリプトを書いてみた。(restsmk.pl)
perl の Crypt::SSLeay モジュールを OpenSSL 0.9.8a を使ってコンパイルしてみた。nmake test を実行してテストを行ってみると、perl (ActivePerl 5.8.7) がエラーを起こして異常終了してしまった。OpenSSL 0.9.7i を使ってコンパイルし直したところ、問題は起きなかった。
Jcode 2.03 の ppm パッケージを作ってインストールしてから、perl -MActivePerl::DocTools -e UpdateHTML でドキュメントを更新したところ、日本語ドキュメント (Nihongo.pod) が文字化けしてしまった。euc-jp で書かれているが、HTML で文字コードの指定がなされていないのが原因のようだ。一応ブラウザで文字コードを指定し直して読み込めば文字化けは直るが、面倒だ。HTML ソースを見てみると、アンカー文字列が文字化けしているのも気になる。Nihongo.pod を Shift_JIS に変換してから、ドキュメントを更新したところ、ブラウザでの文字化けは起きなくなったが、アンカー文字列はさらにひどく化けてしまった。閲覧に支障はないが、何だかなぁ。まあ、Windows 上では Shift_JIS の方が都合がよいので、このままにしておこう。
> ppm install http://homepage3.nifty.com/k-takata/perl/Jcode-2.03-5.8.x.ppd
ppm をいろいろ試してみたが、以前はインストールできなかったパッケージが、かなりインストールできるようになってきたようだ。とりあえず Crypt-SSLeay 0.51, Jcode 0.88, XML-RSS 1.05 はインストールできた。リポジトリには Unicode-Japanese 0.31 も登録されているようだが、こちらは Unicode-Japanese.ppd が見つからないというエラーが出てインストールできなかった。他には、HTML-Format は、リポジトリに登録されていなかった。
先月の spam メールの集計結果。着信拒否にならなかった spam が 1820通。そのうち、@nifty の迷惑メールフォルダーでも Spam Mail Killer でも spam として認識できなかったものが 5通(0.27%)。誤削除が 3通。今までヘッダーだけで判断して削除できていなかった spam を徹底的に分類して、新しい削除条件（複数要素）を 10個ばかり設定したところ、spam 検出精度がかなり向上した。さらに、本文を受信する回数が大幅に減ったので、メールのチェック時間もかなり短縮された。また、メールのチェック時間を短縮させる別の方法も現在実験中である。
相変わらず、@nifty の迷惑メールフォルダーの学習状況は良くない。やはり、info@ 系の spam を spam として分類してくれないことが多い。学習をやり直した頃から「学習型フィルターで検出した迷惑メール数」が減っているように見える。
SMK の判定処理を高速化させるために数日前から試していた物がようやく形になった。PLS9xx.TXT の処理時間が非常に長いので、正規表現を使って IP アドレスをチェックしてみることにした。手で正規表現に直すのは非常に大変なので、PLS9xx.TXT を読み込んで正規表現に変換する Perl スクリプトを書いた。正規表現を簡略化するための処理を書くのにかなりの時間が掛かった。早速、「メールチェックの簡易テスト」を使って、処理時間を確認してみたところ、今まで 1.5秒程度掛かっていたものが 0.5秒未満で処理することができるようになった。
ただ、この方法には少し問題があり、PLS9xx.TXT とは違い、X-Originating-IP: [xxx.xxx.xxx.xxx] が含まれていても、ヘッダー内の全ての IP アドレスをチェックする。また、smknoip.txt も無視され、ヘッダーの全ての行がチェック対象になってしまう。そのため、誤削除の確率は PLS9xx.TXT を使うより高くなってしまう。
変換スクリプト: ip.pl
韓国（.kr）経由の削除: FGL900.TXT
中国（.cn）経由の削除: FGL901.TXT