ソフトウェアに関する不具合、要望、感想 - 1269072321

1：Y.Takanashi(少女遊霊姫/高梨怜奈)★：2010/03/20(土) 17:05:21 ID:???0: ・不具合報告の場合、まず「最新バージョンを確認」してから以下のテンプレートに従い、報告してください。
※[]は一例
【OS】[Windows XP SP3]
【ソフト名】[archer]
【バージョン】[Ver.0.0.1.0]
【症状】[7z書庫ファイル以外が選択できない]
【再現手順】[1.「Add Files」をクリック 2.zipやlzh書庫を選択しようとしても不可]
・要望、感想については、ご自由にどうぞ。
549：tenteko：2020/03/20(金) 21:08:02 ID:4Hi1m3GA0: ＞これはメッセージを投げる前にファイルの解凍が終わっていることが原因のようです。

なるほど。
となると、多くの画像ファイルが入ったアーカイブ（LZMA2圧縮）を解凍したときに、
最後付近のファイルについてARCEXTRACT_BEGINが送出されていなかった現象が
時々発生していたのですが、これについても同じ原因と考えられそうです。

＞ただ、解凍処理が終わっているのにメッセージを投げ続けるのはどうかなと思いますので、
＞この修正については見送らせてください。

了解いたしました。
となりますと、これまでARCEXTRACT_BEGINに依存した処理をしていたのですが、改めることにしました。

これを受けまして、今現在、『どのファイルまで解凍したか』というのを判断するために、
次のような処理をしております。

＝＝＝＝＝＝＝＝＝＝

①SevenZipFindFirst及びSevenZipFindNextにより取得したファイル情報を順に配列に保存。
また、各ファイルがこの後確保するバッファのどの位置に解凍されるかも一緒に保存しておく。

②SevenZipGetArcOriginalSizeExによって解凍される全ファイルのサイズを取得し、
そのサイズでバッファを作成。

③バッファに対し、①のデータをもとに、各ファイルの先頭位置にダミーのデータ（1byte：値0x11）を
書き込んでおく。

④バッファに対し、別スレッドでSevenZipExtractMemExによる解凍開始。

⑤1/60秒毎に、③でデータを書き込んだ各位置を調査し、ダミーのデータと異なる値が書き込まれていれば、
直前のファイルの書き出しが完了したものとみなし、当該「直前のファイル」の書き出し完了のフラグを立てる。

⑥各ファイルの書き出し完了フラグを調査し、フラグが立っていれば（複数の別スレッドで）逐次
読み込みを開始する。

⑦また、任意のタイミングで解凍を中断（コールバック関数でreturn false）し、
SevenZipExtractMemExの終了を待って、別のアーカイブの解凍を開始する（①に戻る）こともできる。

＝＝＝＝＝＝＝＝＝＝

…以上の処理をしている中で、時々次のような現象が発生します。
沢山の画像ファイルが入ったアーカイブを解凍するという場合についてですが、

(1)コールバック関数で受信したメッセージから書き出したサイズが取得できますが、
これが最大値（全ファイルのサイズ）になっているにもかかわらず、

『全てのファイルについて書き出し完了のフラグが立たない（全く書き出されていない？）』

『最後の方で書き出される、連続する幾つかのファイルについて、書き出し完了のフラグが立たない、または
フラグが立っても正しいファイルとして読み込めない（ある地点から書き出しがストップしている？）』

という現象が時々発生します（同じアーカイブを読み込み直すと正常に解凍できたりします）。
7zipではなく、通常のzipの場合に発生しやすいような印象で、
特に⑦によって連続で解凍や中断を繰り返していると発生しやすい、
というのが体感的な印象でしょうか。

(2)書き出し完了のフラグが立っているファイルを読み込みに行っても、
壊れた画像ファイルとして表示されることがあります（書き出し途中のファイルを読み込んだ感じです）。
ただし、もう一度読み込み直すと正常に表示されます。
これも通常のzipの場合に発生しやすいような印象です。

（続く）
550：tenteko：2020/03/20(金) 21:08:38 ID:4Hi1m3GA0: （続き）

そこで、幾つか質問があるのですが、

(a)SevenZipExtractMemExでは、SevenZipFindFirst及びSevenZipFindNextで得たファイル（とフォルダ）の順に
書き出しが行われているのでしょうか。

(b)SevenZipExtractMemExは、バッファに対し、バイト単位でシーケンシャルに
書き出しを行っているのでしょうか。
（上記(2)からの推測ですが、飛び飛びにデータが書き出されたりすることもあるのでしょうか）

(c)ARCEXTRACT_BEGINは直前のファイルの完全な書き出しを保証してはいないように
思えるのですが、これは正しいでしょうか。

(d)同様に、ARCEXTRACT_ENDは最後のファイルの完全な書き出しを保証してはいないように
思えるのですが、これは正しいでしょうか。

(e)また、コールバック関数で受信したメッセージ(EXTRACTINGINFOEX64)より得た書き出しサイズは、
そのサイズまでシーケンシャルに書き出したことを保証していないように思えますが、
これは正しいでしょうか。

(f)SevenZipExtractMemEx()の関数が終了し、その後に処理が移ったとしても、
裏ではまだバッファへの書き出しが行われている、という状況は有り得ますでしょうか。

(g)上記(1)の２つ目の現象からの推測なので、その推測が外れていれば意味のない質問なのですが、
例えば、解凍の処理は一定のブロック単位で解凍→書き出しを繰り返しているとして、
最後のブロックの書き出しだけ失敗する、ということは有り得ますでしょうか。

(h)上記(a)が正しいとして、その順で、あるファイルまで確実に書き出された、
ということを知る方法はありますでしょうか。

…以上、長々と失礼いたしました。

現在の処理方法（ダミーデータが上書きされれば直前のファイルは解凍済み）でも
大体は上手く処理できているのですが、たまに発生する上記の問題の対処に難儀しておりまして、
そのため幾つか質問させて頂きました。

何度もお手数をおかけしている中で申し訳ありませんが、
宜しくお願いいたします。