GSFinderのバグ検証・Unzip.dll編
先日id:soliptさんから報告のあった、不正なZIP書庫が作成されてしまう件、原因が判明したのでご報告。
同じDLLを使っても、Exぱんだで作成した書庫は正常なのにもかかわらず、GSFinder+*1で作成した書庫は不正なものになってしまうというバグだったわけですが……。
同じプログラムで入力も同じなら、同じデータが出力されなければおかしいわけで、じゃあ違うのは入力か？ ということで、調べてみましたよ、渡されたパラメータをファイルに出力する専用のUnzip.dllを作って*2。
以下、My Documentsフォルダのtest.txtを圧縮して、ルートフォルダのtest.zipに出力しようとした場合のパラメータを1個1行で出力したものです。なお、ハイフンの列は見やすいように足したもので、パラメータではありません。
EXぱんだ ---------- -a \test.zip \My Documents\ \My Documents\test.txt ----------
GSFinder+ ---------- -a \test.zip \My Documents\ \My Documents\test.txt ----------
えーと、なんでしょうね、最後の空行？ ちなみに完全な空行で、空白文字が含まれていたりはしません。
不思議に思ってGSFinder+内部で生成されているパラメータ文字列を見てみたのが以下。シングルクオートは見やすいように(以下略)。
'a "\test.zip" "\My Documents\" "\My Documents\test.txt" '
ああ、なるほどね。などと理解できてしまうあたり、我ながらちょっとアレですが。
どこが問題かといえば、末尾の空白。多分、これが「パラメータ区切り」として認識されて、末尾に「長さ0の文字列」が付いていると判定されているんでしょう。その結果が前述の空行ではないかと。そしてUnzip.dllは、その「長さ0の文字列」を「ファイル名」として処理して不正な書庫を作成する、と、まあこういう感じでしょうね。
そんなわけで、Unzip.dllに渡すパラメータ文字列を作成する処理の中に、末尾の空白文字を削除する処理を入れたら、不正な書庫が作成されなくなりました。WindowsCEでUnzip.dll(もしかしたらUnlha.dllも)を使う場合には、パラメータ文字列の作り方には気をつけましょう。
