2006/03/28(火)Memo移行

2006/03/27 26:34 PC(全般)
Memo用のCGIを華式からSerene Bachに変更した。

変更の理由としては、華式のバグが使えば使うほどボロボロ出てくることや速度など色々。作者が1人で他に使用ユーザが少ないことも一因ではある。機能の豊富さに関しては非常に優秀なCGIであったのだが……

最後にメモ替わりに華式に関して気づいたバグ・不満点等


  • 検索が全体に適応されない

  • リファが大量にあると個別記事のレイアウトが崩れる

  • 非公開の記事が非公開になってないことがある

  • リファのリンクが別の記事に飛ぶ

  • テンプレートの仕様がちょくちょくかわる


Serene Bachのいいところは


  • 比較的軽い

  • 動的・静的のどちらにも対応可

  • テンプレート・プラグインの仕様がある程度明確

  • Wiki記法対応


欠点もある


  • アクセス解析が何かおかしい(カウントされてない?)

  • Serene Bachへの移行が結構たいへん(だった)

  • プレビューがない

  • 各記事に編集ボタンを付けられない(記事の修正が面倒)


Serene Bachへも腰掛けになる可能性があるが、1年位はこれでいってみるつもり。

2006/02/27(月)Neroのファイル名文字種制限と、ボリュームラベル制限について調査

2006/02/27 19:00 PC(全般)
Nero Burning ROMを久々に触ったので、日本語ボリュームラベルやWindowsにおける微妙な文字を含むファイル名がどうなるかを調べてみた。
調査対象バージョンは、Nero Burning ROM 7.0.5.4。

ボリュームラベル入力欄に、

12345678901234567890

と入力し、

ABC!#$%&',; ()=^-[]`+.test

という名前の、怪しいファイル名を付けた1ファイル(中身はテキスト)を焼いてみてテスト。Win32においては、,(カンマ)と;(セミコロン)が大分怪しい(MS的には付けるべきでないファイル名だが普通に付けられる)。

設定によって多少結果が変わったので、以下メモ。

●CD-ROM(ISO)で焼いた場合(jolietファイル名にセミコロンを許可オプションにチェックしない)

・ファイル名は;が_に変更される
・ボリュームラベルは"1234567890123456"となる

●CD-ROM(ISO)で焼いた場合(jolietファイル名にセミコロンを許可オプションにチェック)

・セミコロン(;)以降の文字列がファイル名として認識されない(ファイル名がABC!#$%&',に化けた)
・ボリュームラベルは"1234567890123456"となる

●CD-ROM(UDF)で焼いた場合

・ファイル名は元のまま
・ボリュームラベル入力欄に"123456789012345"までしか入力できない。またなぜかボリュームラベルをひとたび保存すると、"1234567・_"などと8文字目以降が文字化けるので、焼き込み直前の最終チェックが必要。

●CD-ROM(UDF/ISO)で焼いた場合(jolietファイル名にセミコロンを許可オプションにチェックしない)

・ファイル名は;が_に変更される
・ボリュームラベルは"123456789012345"となる

●CD-ROM(UDF/ISO)で焼いた場合(jolietファイル名にセミコロンを許可オプションにチェック)

・ファイル名は元のまま
・ボリュームラベルは"123456789012345"となる

結論として汎用性が最も高いのはセミコロンを許可した上でのUDF/ISOとなった。CD-ROM(ISO)でも大して変わらないのだが、セミコロンを含むファイルがほとんど無いことをさっ引いても、ファイル名が自動的に削られ(たように見え)るのは腹立たしい。というか不安。

Neroではボリュームラベルは半角全角問わず16文字までという仕様。ただUDFとUDF/ISOの場合は、なんでISOより1文字余計に切られるんだろう??? UDFはボリュームラベル文字化けが不安。確認を怠ると頻発する羽目になる。なお、これらのフォーマット設定による現象はDVDでもCDでもほぼ同じ結果になった。

セミコロンを許可オプションの有無に対するファイル名の検査と変更は単にファイルをウェルにD&Dした時に行われる。従ってD&D後にオプションを変更してもウェル上のデータには反映されないようだ。微妙な仕様。この変更が行われるのはISOもしくはUDF/ISO時のみで、UDF時はオプションに関わらずファイル名の変更は行われない。


ちなみにAplix WinCDR9.0.2だと、

・;と,は書き込み時に変更を要求される(絶対に書き込めない)
・ボリュームラベルは32byteまで(上記の例だと"1234567890123456")となる

さて、以前は日本語ボリュームラベルといえばWinCDRだったが、ついにNeroも追いついてきたようだ。とはいえボリュームラベルはまだWinCDRの方が自由度が高い。全角では1文字差があるかないかだが、半角だとNeroが16文字でWinCDRが32byteだから大分差がある。とはいえタイムスタンプの保持や、(勘違い:タイムスタンプは保持される),が含まれたファイル名の書き込みなどWinCDRに出来ないことも多い。しかし、今ひとつNeroの実装には不安が多いのでいつも体験版使ったあとで購入を躊躇してしまう。今回はどうしよう……

2006/02/27(月)CD/DVDのボリュームラベルが更新されない

2006/02/26 27:00 PC(全般)
ずっと、エクスプローラからCD/DVDのボリュームラベルが更新できない問題に悩まされていたのだが、
http://support.microsoft.com/default.aspx?scid=kb;ja;817357
なんとSP1の問題だったらしい。

仕方ないので観念してついにSP2を入れることにする。さて何が起こりますことやら…

[2006/02/27追記]
問題も起こらず、直りもしなかった。エクスプローラ以外からはちゃんとボリュームラベルが見えるのだが…… むしろエクスプローラがF5おしてもキャッシュを手放さない理由が知りたい。

2006/02/24(金)Rubyでコンソールから1文字入力

なつかしのC言語だとgetch()あたりで簡単に出来るコンソールからの直接1文字入力。Rubyの標準機能だとどれを使ってもEnterを押されるまで読み込めない。別に我慢すればいいような話なのだが、ちょっと挑戦。

・解決案1(不採用) 添付ライブラリcursesを使う。Winでもunixでも動くには動きそうだが、表示とかが機種依存ぽいので止め。

・解決案2(採用) Win32API+crtdll.dllを使う。もちろんwin32限定だが、その範囲に限れば最も機種依存度低そう。(msvcrt.dllよりもcrtdll.dllの方が汎用性高いという認識で合ってるよね?)

ということで解決案2でGO。

こんなふうに書いてみた。
require 'Win32API'

func_getch = Win32API.new('crtdll.dll', '_getch', 'v', 'i')

str = "Do you like skate? [y/N]\n"
print str

while true do
	x = func_getch.call.chr.downcase
	
	case x
	when 'y'
		#yesの時の処理
		print "Ok!\n"
		break
	when 'n', "\r"
		#noの時の処理(デフォルト)
		print "Terrible!\n"
		break
	when "\C-c"
		#getchでコンソールを奪うと中断出来ないので
		exit
	else
		print str
	end
end
如何にも古い人のコードだが気にしないで欲しい。

Win32API->crtdll.dll経由で_getchを呼び出す。_getchはエコーしないのであとは入力された文字で処理を分けてやるだけ。

意外と簡単に書けたけど…… こんなの使うのかな?

[参考URL]
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/6991

2006/02/24(金)coLinux+samba > Windows+ファイル共有?

2006/02/24 18:00 PC(Linux)
Windowsのファイル共有を使っていたところ、ファイル数が多いディレクトリでファイル名の列挙に時間がかかることに気づいた。状況を整理すると、

・ファイルサーバ側(WinXP SP1)、クライアント側(WinXP SP1)
・クライアント側からNBTでサーバ側のディレクトリにアクセスしたときに発生
・サーバ側のファイル数は600程度で日本語を含む
・ファイルの列挙(要はdir/ls)にかかる時間は4秒程度
・ファイルの列挙に時間がかかるだけで、転送速度そのものが遅くなっているわけではない
・パケットをキャプチャしてみたが余計なパケットは飛んでいないように見える
・dirで確認すると一定の転送量ごとに何かがつっかえている感じ
・サーバー側・クライアント側入れ替えても発生
・クライアント側からLinux+sambaの自宅サーバにアクセスするとこの現象は発生しない

フォーカスが移るたびに読み直すファイラー(春M)でアクセスするから困るのであって、実はエクスプローラだとそんなに問題はない。また、1ディレクトリに100も200もファイルを置いている方がおかしいと言われればそれまで。レジストリの調整で解決できそうな予感はあるのだが、情報としては発見できなかった。

一応実験としてcoLinuxをサーバ側にインストールし、sambaで共有して速度が向上するか確認することにする。coLinuxのネットワークはホストマシンのNICとブリッジ接続にする。coLinuxからcofsでホストマシンのディレクトリをマウントし、sambaで共有させた。

結論から言うと、ファイル名の列挙に関しては速度が向上したが、根本的なアクセス速度が落ちた。netperfによる簡易計測であるが、クライアント側からスループットを比較したところホスト側(WinXP)では90~92Mbps、ゲスト側(coLinux)では47~48Mbpsとなった。なんと2倍近い差がある。アクセス速度に関しては、1000Mbpsで繋げば簡単に向上するかもしれないが、実験していない。これはそのうち追試。またこの方法の問題として、日本語ファイル名を下位に含むディレクトリではcofsで総ファイルサイズが取得できない(dfからしてinput/output Errorとなる)。結局魔法のステッキにはなってくれないようである。

win32版sambaとかあればなあ……(バカ)

暫定的な解決手段としては、ディレクトリ整理と春Mをあきらめてエクスプローラを使う。ただもう春Mからは離れられそうにないのでさっさと整理が一番正しい。

2006/02/09(木)coLinuxでsshでログインできない

2006/02/08 25:00 PC(Linux)
色々あってcoLinuxインストール中。
他の所は大して詰まることがなかったのでタイトルの件だけメモ。

sshdを立ち上げたのになんかログインできない。原因は下。

/etc/ssh/sshd.confに

ChallengeResponseAuthentication no

を明示しておかないとログインできないようだ。PAMにされる(ホント?)。
当初はコメントアウトされていた。パスワード認証でいいんだが、明示する必要あったかなあ?

もう忘れてる。酷い。

[参考サイト]
http://nekhet.ddo.jp/item/771
http://www.momonga-linux.org/archive/Momonga-devel.ja/msg03147.html

coLinuxのインストールの流れはこちら
[参考サイト]
http://scratchpad.fc2web.com/colinux/install/index.html
OK キャンセル 確認 その他