2006/02/27(月)Neroのファイル名文字種制限と、ボリュームラベル制限について調査
2006/02/27 19:00
調査対象バージョンは、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だから大分差がある。
2006/02/27(月)CD/DVDのボリュームラベルが更新されない
2006/02/27 03:00
http://support.microsoft.com/default.aspx?scid=kb;ja;817357
なんとSP1の問題だったらしい。
仕方ないので観念してついにSP2を入れることにする。さて何が起こりますことやら…
[2006/02/27追記]
問題も起こらず、直りもしなかった。エクスプローラ以外からはちゃんとボリュームラベルが見えるのだが…… むしろエクスプローラがF5おしてもキャッシュを手放さない理由が知りたい。
2006/02/24(金)Rubyでコンソールから1文字入力
2006/02/24 22:00
・解決案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
・ファイルサーバ側(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/09 01:00
他の所は大して詰まることがなかったのでタイトルの件だけメモ。
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
2005/10/27(木)ApolloのPanelでinitializeがオーバーライドできなかった理由
2005/10/27 02:00
class MyPanel < Phi::Panel def initialize # ≪処理≫ end end MyPanel.newというコードを書いたのだが、≪処理≫が実行されない(本来なら処理の前にsuperを書くが、わかりやすくするために削った)。
で、この場合newで呼ばれるのはPhi::Panelのコンストラクタのようで、オーバーライドしたはずのinitializeを通らない。
これはどうやらPhi::Panel上でnewが再定義されている所為らしい。下はGtkの記事だがApolloでも似たようなことをやっているのではないかと推測。再定義したnewはinitializeを呼ばないという解釈で良いと思う。
http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-list/5885
いやちゃんとソース読んで無いので確証はないのだが(読み方すら分からない)。
ということで、
class MyPanel < Phi::Panel def MyPanel.new # ≪処理≫ end end MyPanel.newとしてやれば願いが叶う。newはクラスオブジェクトのメソッド(こういう言い方でいいんだっけ?)なので、def newではなく、def MyPanel.newと書く。superは省略したが、ちゃんとやるならもちろん返り値の設定までしてやらなきゃいけない。
ret = super ≪処理≫ ret≪処理≫の中でプロパティいじるような目的がほとんどだと思うので、こんな書き方が定番になるんだろう。initializeと大きく異なるのはこの中でselfを呼ぶとクラスオブジェクトが返ってくることだ。
class B end class A < B def A.new ret = super p self ret end end p A.new --出力-- A #<A:0x2bb42c8>つまりこうか。
プロパティを設定するときはsuperの返り値(ここではret)に対して設定してやらなきゃならない。
#追記
newからinitializeを呼んでやった方が汎用性が高い。
2005/10/21(金)aviutlフィルタの対応表
2005/10/21 12:00
http://page.freett.com/dtvshitsumon/
2005/10/20(木)RAIDをStandard IDEとして使えるのかどうか
2005/10/20 16:00
調べた結果、「ほとんどのチップで単独のIDEデバイスとして使える機能はついているが、それが使えるかどうかはBIOS・ボードディップスイッチ次第」という結論でよさそう。つまり一概に言えない。
また、特にSATAのオンボードコネクタに関しては、
「Intel系ではサポートされているものがほとんどだが、それ以外のチップセットではBIOS次第」という気配だ。これはチップセットメーカーが提供したリファレンスBIOSで違いが出たんじゃないかと予想。
intel系
http://review.ascii24.com/db/review/hard/videocard/2005/02/24/654390-003.html
VIAの話
VIAチップセット総合スレPart7
http://pc7.2ch.net/test/read.cgi/jisaku/1114019974/175-188
別にシングルIDEデバイスとして使えなくても、スパニングやRAID0だか1だかわかんないArrayが作れるので、そのマシンでトラブル無く使えている限り問題は起きない。がしかし、ひとたびトラブルが起きると(特に金と時間がないとき)死ぬほど復旧がめんどくさくなるのでこの機能があるものを選ぶ方が良いだろう。いろいろ探してみたが、Arrayを作ってしまうと、技術的には簡単そうなミラーリングやスパニングですら簡単に単独のIDEデバイスに戻す方法はないようだ。
で、確認のためには、カタログスペックだとわからないのでマニュアルダウンロードでBIOSの項目を読むしかなさそう。
2005/10/20(木)codec pack
2005/10/20 12:00
ffdshowだと軽くなることもあるが、問題が起こったときに切り分けが大変だというのは経験談。
K-Lite codec pack
http://home.hccnet.nl/h.edskes/mirror.htm
http://home.hccnet.nl/h.edskes/mirrorold.htm
DivX等も入っていて、これ1つで済むのは便利。
古いのは下。だいたいFullで十分でMegaは行き過ぎっぽい。
これグレイだよな多分。
なお、インストール時にコーデックを選択可能で、すでにインストールされているものに関してはアンインストールを指示される。拒否するとそれについてはK-Liteからインストールできない。
本来のコーデックインストーラに言語選択があるようなものでも全部英語になる(ちゃんと確認してない)。