ソフトウェアに関する不具合、要望、感想 - 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書庫を選択しようとしても不可]
・要望、感想については、ご自由にどうぞ。
547：tenteko：2020/03/13(金) 01:30:02 ID:4Hi1m3GA0: ＞標準出力の割り当てに失敗していたことが原因です。
＞これを回避するために、裏でcmd.exeを立ち上げたりしています。

ちょっと私にはまだ難しいようです…。
でも、今後のために覚えておきます！

＞二重引用符

これはそのようにさせて頂いたところ、バッチリ動作しました！
ありがとうございます。

さて、ARCEXTRACT_BEGINがLZMA2解凍時に送出されない件についてですが、
テスト用のファイルを用意しましたので、確認いただけますでしょうか。
参考までに、私の環境下で解凍した場合の、それぞれのメッセージの送出状況を
記しておきます。

ttps://30.gigafile.nu/0320-de726bea80631e3bd8ff85c1ad8cbcaa7
ファイル名：test_arc_files.zip
ダウンロードパスワード：arc

●test_LZMA.7zの場合（LZMA圧縮）

ARCEXTRACT_OPEN
ARCEXTRACT_BEGIN (フォルダ"test_LZMA"の解凍)
ARCEXTRACT_BEGIN (ファイル"test01.png"の解凍)
ARCEXTRACT_BEGIN (ファイル"test02.png"の解凍)
ARCEXTRACT_BEGIN (ファイル"test03.png"の解凍)
ARCEXTRACT_INPROCESS (ファイル"test03.png"の解凍)
ARCEXTRACT_END

●test_LZMA2.7zの場合（LZMA2圧縮）

ARCEXTRACT_OPEN
ARCEXTRACT_BEGIN (フォルダ"test_LZMA2"の解凍)
ARCEXTRACT_INPROCESS (フォルダ"test_LZMA2"の解凍？)
ARCEXTRACT_END
548：x@rgs★：2020/03/14(土) 12:49:25 ID:???0: >>547

LZMA2の件ですが、提供していただいたアーカイブで確認できました。
これはメッセージを投げる前にファイルの解凍が終わっていることが原因のようです。
Dialog.cppのCProgressDialog::SetCompleted()内、
if (m_nCompletedSize == nSize)
return;
をコメントアウトすればメッセージが送出されます。
ただ、解凍処理が終わっているのにメッセージを投げ続けるのはどうかなと思いますので、
この修正については見送らせてください。
申し訳ないです。
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)が正しいとして、その順で、あるファイルまで確実に書き出された、
ということを知る方法はありますでしょうか。

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

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

何度もお手数をおかけしている中で申し訳ありませんが、
宜しくお願いいたします。
551：x@rgs★：2020/03/30(月) 01:58:06 ID:???0: >>549-550

返信が遅くなり申し訳ございません。
ご質問いただいた内容は内部処理に関することですので、確実な回答はちょっとできません…

とりあえず、SevenZip()のメインスレッド終了時に標準出力をフラッシュするようにし、
また標準出力に割り当てるパイプをCreateFile(FILE_FLAG_NO_BUFFERING)で作成してみました。

tenteko様の現象が再現できていないため、不具合が修正できているか分かりませんが…
よろしくお願いします。
552：tenteko：2020/04/05(日) 01:12:27 ID:4Hi1m3GA0: こんにちは。
毎回対応して下さり、ありがとうございます。

１週間弱ほど新しいバージョンを試させて頂いた結果を報告させていただきたいと思います。

前回報告させて頂いた不具合（(1)と(2)です）については、
これはどちらも再発しなくなりました（今のところは、ですが）。

ただその代わり、前バージョンではそんなことはなかったと思うのですが、
今バージョンではSevenZipExtractMemEx()がフリーズする現象が再発するようになりました。

恐らくですが、書き出しが開始した時点でフリーズしているように思えます。

発生する条件は未確定なのですが、次のような場合によく発生するように思えます。

(a) zipの解凍時によく発生するように思える（7zipの場合は無い…ように思える）

(b) やはり解凍中断→解凍開始とした場合に発生しやすいように思える
　　（「初回解凍」や「解凍完了→解凍開始」の場合も発生するかどうかはよくわかりません）

ただ、次のような処理をすると、高い確率でフリーズが再現できます。

(c) 画像の入ったzipを沢山用意し（何百個単位）、各zipに対し、
　　その中の最初の画像ファイルだけを解凍し、これをサムネイル化する
　　…ということを順に繰り返していく

なお、この(c)の処理において、SevenZipExtractMemEx()の直後にウェイトを入れてみたところ、
ウェイトの量が多いほどフリーズしにくいような印象ではありますが、
あまりこの手は使いたくないところです。

以上となります。
宜しくお願いいたします。
553：x@rgs★：2020/04/12(日) 02:53:12 ID:???0: >>552

ご報告ありがとうございます。
なかなか解決できず申し訳ないです。

フリーズについて、パイプ読み込みスレッドの終了・中断処理を改善しました。
今のところAutoHotkey環境で動かしている分にはフリーズしなくなったようです。

この修正で>>549で報告いただいたファイルの一部が出力されない不具合も改善されたかもしれない…
ということで、CreateFile(FILE_FLAG_NO_BUFFERING)に加え、従来のCreatePipe()版も同梱しています。
さらに、標準出力のフラッシュあり・なしで分けてあり、合計4種類あります。

お手数をおかけしますが、「01_CreatePipe版_FlushFileBuffersなし」から動作を確認していただき、
不具合が発生するようでしたら他のバージョンもお試しください。

よろしくお願いします。
554：tenteko：2020/04/17(金) 21:40:45 ID:4Hi1m3GA0: 今回はそれほど試せなかったのですが、一通り試してみた結果を報告します。

●01_CreatePipe版_FlushFileBuffersなし

前回の報告にあった「連続で各zipのサムネイルを一つずつ作る」という場合は問題なかったのですが、
通常通り全解凍する場合、検索順序で言うところの最後の方が解凍されない、という症状は出ました。

●02_CreatePipe版_FlushFileBuffersあり
●03_FILE_FLAG_NO_BUFFERING版_FlushFileBuffersなし
●04_FILE_FLAG_NO_BUFFERING版_FlushFileBuffersあり

これらは全て問題がないように思えます。

というわけで、もしかしたら安定したかも！　です！

まだ上記「連続で各zipのサムネイルを一つずつ作る」という機能を本格実装していないので、
なかなか物量的な実地調査はできていないのですが、引き続き調査してみたいと思います。

…ところで、画像ビューワーを現在作っているわけですが、悩んでいることがあります。
やりたいこととしては、次の２つを同時に行いたい、ということなのですが…

①アーカイブ内の画像（閲覧する対象）をオンメモリに解凍。

②別スレッドで並行して「連続で各アーカイブ（主に閲覧してないもの）のサムネイルを一つずつ作る」

…ここで問題となってくるのが
「①と②で実行した各SevenZipExtractMemEx()が、共通する１つのコールバック関数にメッセージを送る」
ということなんです。

そうなると、例えば「①は中断したいが②は中断したくない」という場合に
コールバック関数で return false してしまうと、両方ともが中断してしまう…という結果になってしまいます。

そこで、もしかしたらdllファイルをコピーしてリネームし、これをLoadLibrary()すればいけるかな？
と試してみたのですが、やはり１つのコールバック関数に双方のメッセージが送られてしまうように思います。

…なにか良い方法は有りませんでしょうか。
毎回お手数をおかけします…。

■追伸
４つのdllの調査の優先順位は、01が最優先で、順に04まで優先順位が下がっていく、
という感じに調査すればいいでしょうか。
555：x@rgs★：2020/04/20(月) 21:27:14 ID:???0: >>554

ご報告ありがとうございます。
問題がなければ「02_CreatePipe版_FlushFileBuffersあり」を採用していきたいと考えています。
優先度は数値の順番で、01がダメなようなので、02→03→04でお願いします。

1つのプロセスでの並行処理は難しいと思います。
・中断を判断するフラグがグローバル変数のため、1つを中断すると全ての処理が中断してしまう。
・他にもグローバル変数が存在。
・dllファイルをリネームして読み込んでも、プロセスごとに割り当てられる標準出力を利用するSevenZipExtractMem()は正しく動作しない。
等々。

サムネイル作成処理を別プロセス化して、共有メモリで本体とやり取りする…はいかがでしょう。
556：tenteko：2020/04/26(日) 22:12:42 ID:4Hi1m3GA0: こんにちは。

あれから「02_CreatePipe版_FlushFileBuffersあり」版を試していますが、問題は発生していません。
とても有難く使わせてもらっています。（本当にありがとうございます！）

前回教えて頂いた別プロセス＋共有メモリという方法について少し調べてみました。
メモリマップトファイル…というものを使うらしいのですが、合っていますでしょうか。

これを使うかどうかは思案中でありますが、ひとまずは同一プロセス内で
各アーカイブのサムネイルを作れるように実装してみましたところ、
割とテンポよくサムネイル作成ができるようになりました。
（SevenZipExtractMemEx()が並行実行されないようにアーカイブのサムネイル作成をしています）

ただ、ここで一つ、別の問題が発覚しました。
例えば、サムネイル作成しようとしているアーカイブ（7zの場合を想定）内にファイルが8個格納
されているとして、その解凍される順序が次のようになっている場合、

①画像ファイル以外のファイル
②（上に同じ）
③（上に同じ）
④（上に同じ）
⑤画像ファイル
⑥何らかのファイル
⑦（上に同じ）
⑧（上に同じ）

SevenZipExtractMemEx()には⑤だけを解答するように指示したとします。
ここで、例えば②の処理をしている時点で中断の指示を出した場合、
②の処理が終わった時点でSevenZipExtractMemEx()が終了してくれればよいのですが、
そうはならず、（恐らく）⑤の処理を終了するまでSevenZipExtractMemEx()は終了してくれない、
という現象が発生します。

これによって、例えば①～④にサイズの大きなファイルが入っている場合、
⑤の解凍を中断する場合にかなり待たされることになったりします。

一方、このアーカイブを全解凍する場合は、どの時点であってもその時点で取り掛かっている
ファイルの処理が終了したらSevenZipExtractMemEx()も終了してくれているように思います。

…そこで要望なのですが、特定のファイルだけを解凍する場合も、全解凍の場合と同じように
中断処理が行えるようにしていただけませんでしょうか。

ここまで対応して頂いた中で恐縮なのですが、宜しくお願いいたします。
557：x@rgs★：2020/04/29(水) 10:23:11 ID:???0: >>556

ご報告ありがとうございます。
CreatePipe()とFlushFileBuffers()の組み合わせでいきたいと思います。

メモリマップドファイルをCreateFileMapping(INVALID_HANDLE_VALUE,...)で作成して、
CreateProcess()でサムネイル作成用プログラムを起動し、書庫を開いてサムネイルを読み込んで…という手順になると思います。
開く書庫やサムネイルのファイル名は引数なり環境変数で渡して、メモリマップドファイルのオブジェクト名もそのように渡すか、
ハンドルを継承できるようにしてハンドルそのものを渡す…とか。

部分解凍の件について、
>SevenZipExtractMemEx()には⑤だけを解答するように指示したとします。
これは「x -hide <書庫名> -ir!<⑤ファイル名>」(もしくは-ir!なし)を指定しているということで間違いないでしょうか。
いくつか書庫を作って試していますが、コールバック関数では⑤の情報しか受け取れないため、なかなか再現できません。
処理手順や書庫について、もう少し情報をいただけるとありがたいです。(書庫を送付していただけるとよりありがたいです)

よろしくお願いします。
558：tenteko：2020/05/03(日) 19:29:46 ID:BrCfT3Wc0: こんにちは。
別プロセスの作り方も教えてくださり、ありがとうございます。とても参考になりました。
まだあまり理解していないのですが、openSiv3D自体に子プロセス作成とパイプライン？の機能があるようで、
これを使えばもしかしたらもうちょっと簡単になるのかも…という気がしております。

＞これは「x -hide <書庫名> -ir!<⑤ファイル名>」(もしくは-ir!なし)を指定しているということで間違いないでしょうか。

はい、そのとおりです。
アーカイブのサムネイル作成時に渡しているコマンドは次のようなものです。

x <書庫名> -ir!<⑤ファイル名> -hide

ちなみに、全解凍時に渡しているコマンドは次のようになっています。

x <書庫名> -hide

＞処理手順や書庫について、もう少し情報をいただけるとありがたいです。

中断処理手順の概要を以下に記してみようと思います。

(1) まず、あるアーカイブ（7z）のサムネイル作成にとりかかります。
ここでは、SevenZipFindFirst()とSevenZipFindNext()で最初にヒットした画像ファイルを対象とし、
このファイルのみ解凍するため、上記の最初のコマンドラインでSevenZipExtractMemEx()を起動します。

(2) SevenZipExtractMemEx()実行中、任意のタイミングで中断指示を行います。
具体的には、中断指示　＝　グローバル変数の中断フラグをオンにして、
コールバック関数内でこれがオンの場合には return false するようにしています。

(3) 全解凍の場合は、殆どのケースで中断指示 → 間もなく return false → SevenZipExtractMemEx()終了となります。
しかし一部解凍の場合は、対象ファイルが処理されるまでに大きなファイルが有る場合は、
中断指示を出してもSevenZipExtractMemEx()終了までに時間がかかってしまうことがあります。

…今回、コールバック関数のメッセージの受信状況を調べてみました。
以下のテストファイル（interruptionTest.7z）を使って調べました（大きなサイズで恐縮です）。

ttps://18.gigafile.nu/0510-l69ad0d3859cb18f7f9171bcc91cc3e48

このファイルでは、解凍される順で①～③までがサイズの大きいファイル、
④～⑥が画像ファイルとなっています。

解凍対象となるのは④（test01.png）です。

SevenZipExtractMemEx()が実行されましたら、メッセージは次の順序で送られていました。

(1) ARCEXTRACT_OPEN（interruptionTest.7z）
…（長いインターバル）…
(2) ARCEXTRACT_BEGIN（interruptionTest\\test01.png）
(3) ARCEXTRACT_INPROCESS（interruptionTest\\test01.png）
(4) ARCEXTRACT_END

となりますと、中断フラグを上記「長いインターバル」の間にオンにしたとしても、
メッセージが送られてこないことには return false しようがない、
よって、(2)まで待たなければ中断ができない、ということになっていたようでした。

…毎回お手数をおかけします…。
559：x@rgs★：2020/05/05(火) 00:12:13 ID:???0: >>558

ご報告&ファイルのアップロードありがとうございます。現象確認できました。
とりあえず、ソリッド書庫を解凍する場合等で実際に解凍しないファイルの処理中もメッセージを送るようにしてみました。
スキップするファイルの処理中はARCEXTRACT_SKIP(5)を送ります。勝手に追加していますので、今はどこかでdefineしてください。

何度もすみませんがよろしくお願いします。
560：通りすがりの人：2020/05/10(日) 01:46:52 ID:J948jCQA0: 7z公式にて7-Zip 20.00 alphaが上がっておりました。
sevenzip.osdn.jp/
2020-02-06と記載されながらも、updateは二日前となっておりました。
英文を読むと高速化を図った、decode方法を変更しましたとありますが、重要な点はいくつかのBugFixがされてるようです。
bzip2 decoding code was updated to support bzip2 archives, created by lbzip2 program.
Some bugs were fixed.
報告のみです。
561：通りすがりの人：2020/05/10(日) 01:58:07 ID:FnJlBZMA0: 【OS】[Windows 10]
【ソフト名】[gui4ehgm]
【バージョン】[Ver.1.12]
【症状】[貼り付けて実行を選択した後に表示されるURLを追加画面でのURLからSが削除されてしまう]
【再現手順】[毎回なります。Pの後ろにSを追加すればダウンロードできます、毎回手打ちでSを足しているので削除されないようにしていただけませんか]

とても便利に使わせていただいています。ありがとうございます。
562：x@rgs★：2020/05/10(日) 17:27:48 ID:???0: >>560

ご報告ありがとうございます。
本家のソースコードが公開されましたら対応いたします。

>>561

Ver.1.13を公開しましたのでご確認ください。
563：561：2020/05/10(日) 18:37:55 ID:FnJlBZMA0: gui4ehgmのバージョンアップありがとうございました
使わせていただきます
564：tenteko：2020/05/12(火) 00:02:34 ID:BrCfT3Wc0: 今回も対応して下さり、ありがとうございます！
スキップ中の中断も完全に動作しているように思います！

お陰様で作成中のビューワーの動作がかなり快適になってきました。
もしかしたら別プロセスの作成は無くても大丈夫かも…。

これであとは…各ファイルの書き出しが保証された時点でその都度新たな書出完了メッセージが送信されれば
便利だと思うのですが…。
565：通りすがりの人：2020/05/14(木) 05:31:13 ID:fhnnVVhI0: 【OS】[Windows 10 1903 64bit]
【ソフト名】[reces 32bit]
【バージョン】[Ver.0.00r34b]
質問です
/X オプションで、ファイル名に「 ; 」を含むファイルを指定する方法を教えてください
aa;bb.jpgというファイルがあったとして /Xaa;bb.jpg と記述してもうまく動作しません
566：x@rgs★：2020/05/14(木) 20:40:34 ID:???0: >>564
動作確認ありがとうございます。
現在、ARCEXTRACT_*メッセージを修正中です。
書き出し保証は難しいですが、>>544の②に対応するような、処理前に必ず送信されるメッセージを実装したり、
ARCEXTRACT_INPROCESSのタイミングを調整したりしています。
あまり期待せずお待ちください。

>>565
投稿ありがとうございます。
「;」は区切り文字として処理されるため、正規表現で文字コードとして指定するとうまくいくと思います。
/X:raa\x3bbb\.jpg

#今確認すると正規表現検索の場合は部分一致になってしまっているようですので、次回バージョンでは見直す予定です…
567：565：2020/05/14(木) 23:02:47 ID:fhnnVVhI0: >>566
返信ありがとうございます
動作確認しました
568：x@rgs★：2020/05/15(金) 00:21:44 ID:???0: >>564

>>566の内容を反映したものを公開しました。
ファイルの処理前にARCEXTRACT_PREPARE(6)を送出するようにしてみました。
ARCEXTRACT_BEGINは来たり来なかったりしますが、ARCEXTRACT_PREPAREは確実に送出されるはずです。
大抵はARCEXTRACT_PREPARE、ARCEXTRACT_BEGIN、ARCEXTRACT_INPROCESSの順番で送出されますが、
先頭に格納されているファイルの処理時等はARCEXTRACT_INPROCESSがなかったり、ARCEXTRACT_PREPAREとARCEXTRACT_BEGINの順番が逆になったりしてしまいます。
#そのため、ARCEXTRACT_PREPAREが来たからと言って、その前のファイルの処理が終了している保証はありません…

ほかに、ARCEXTRACT_INPROCESSをパイプからの読み込み処理にあわせて送出するようにしたため、コールバックで受けたllWriteSize等からどこまで処理されているかの参考になると思います。

良ければご確認ください。
569：tenteko：2020/05/18(月) 22:45:39 ID:BrCfT3Wc0: いつも要望を取り上げていただき、ありがとうございます。
今回は余り試せていないのですが、明らかな異常がありましたので取り急ぎ報告させていただきます。

すごく重くなりました。

特に、アーカイブのサムネイルを作るために連続で一部解凍を行う場合に顕著で、
解凍が開始される直前ごとに大きな空白時間（１秒位？）が発生しているような感じです。
恐らくですが、SevenZipGetArcOriginalSizeEx()開始後に待たされているように思います。

もしかして…デバッグビルドとかだったり…。
570：x@rgs★：2020/05/19(火) 07:42:43 ID:???0: >>569

ご報告ありがとうございます。
一部クリティカルセクションを削除しました。
ご確認ください。
571：tenteko：2020/05/22(金) 21:26:37 ID:BrCfT3Wc0: こんにちは。
今回も同様の報告となってしまうのですが、
体感的には前回と変わらず（１秒位待たされる）、という感じでした。

また、前回と同様だったかどうかはチェックしていないのですが、
別の問題として、コールバック関数で受信したメッセージでllWriteSizeを拾っているところ、
これが全解凍サイズ一歩手前で止まってしまっているように思います（成功する場合もあります）。
確認いただけますでしょうか。
572：x@rgs★：2020/05/31(日) 13:31:09 ID:???0: >>571

ご報告ありがとうございます。
大変遅くなりました。
恥ずかしいことに、一部デバッグ用コードが残っていたため削除しました。
また、パイプ読み込みで残りサイズに関わらずARCEXTRACT_INPROCESSを送るようにしました。

ご確認ください。
573：tenteko：2020/06/02(火) 23:12:49 ID:BrCfT3Wc0: こんにちは。
何度も対応いただき、本当にありがとうございます。
私ものんびりやっておりますので、どうぞ時間的なことはお気になさらないで下さい。

（以下、報告です）

今回のバージョンでは、前回までの報告に合った不具合（１秒位待たされる・llWriteSizeが途中で止まる）は
無くなったように思います。

ただ、別の問題が発生しました。

まず、解凍を行うとたまにアプリケーションが落ちるようになりました。
VSのリリースビルドでテストをしていると、「7-zip64.dllで例外がスローされました」とエラーが出ます。

もう一つ、llWriteSizeが頻繁にゼロの値を持ってくるようになりました（解凍の途中でも）。
また、再現は難しいのですが、ゼロ以外にもマイナスの値であったこともありました。
574：x@rgs★：2020/06/03(水) 21:42:44 ID:???0: >>573

毎度々々時間が掛ってしまい申し訳ないです。

llWriteSizeが0になる問題については修正しました。
強制終了の件は再現できませんでした…
どのタイミングで、(判明していれば)どの例外が発生しているか教えていただけませんか。
575：通りすがりの人：2020/06/07(日) 23:29:07 ID:PR8eTftk0: >560
です。
非公式DLL便利に使わせて戴いております。
上記ソフトは使用しておりません。
上の7-zip64.dllという書き込みを見てふと思ったのですが
公式ALPHA版にて修正された潜在的なバグが発生しているのでは？
と思った次第です。
以前の公式βも右上にあったと記憶してますが、公開されてるかどうか確認しようと探しましたがソースってどこにあるんでしょうか
公開されれば対応して下さるという記載が御座いましたが。
576：x@rgs★：2020/06/09(火) 08:06:25 ID:???0: >>575

投稿ありがとうございます。
もしかしたら本家側の不具合が関連するものもあるかもしれませんが、
今のところ独自で実装した部分が原因と思われます。

ソースは本家サイトの「Download」(左側)から19.00までなら入手できます。
20.00のソースはまだ公開されていないようです。
577：tenteko：2020/06/11(木) 23:01:51 ID:BrCfT3Wc0: こんにちは。
あれからしばらく動作テストをやってみたのですが、なにぶん不意に落ちるものでして、
なかなか「どのタイミングで落ちるのか」というのがよく分からないまま現在に至ります…。

以下、思いついたことを箇条書きにします。

●基本的には解凍が行われるとき（解凍開始の瞬間か、解凍の最中かはよくわかりません）に
再現性なく不定期に落ちる、という感じです。

●通常の全部解凍の場合も落ちた…ように思います（確か…）。

●サムネイル作成のための一部解凍の場合なんかは解凍回数が多くなるため、
落ちる確率が高くなるように感じます。

●逆に、サムネイル作成のための一部解凍が何百回と繰り返されても、落ちないときは落ちません。

あと、なにかの参考になるかと思い、エラーのスクリーンショットを用意しました。

ttps://20.gigafile.nu/0618-b242e13305ec44af3552f5e7601136cac

メモリアドレス？のような数値は、大体毎回同じものが表示されていました。
余りお役に立てず申し訳ないです…。
578：x@rgs★：2020/06/17(水) 01:13:51 ID:???0: >>577

ご報告ありがとうございます。
手元の環境では再現できなかったため、あやしいところを修正しました。
ご確認ください。
579：tenteko：2020/06/22(月) 21:45:22 ID:BrCfT3Wc0: こんにちは。

最新版をテストしておりましたら、前回報告させていただいた「7-zip64.dllで例外がスローされました」
というエラーは出なくなったようなのですが、次のような問題がありました。

●解凍中断→即別アーカイブ解凍などを繰り返していると、
時々、以下のhArcにnullptrが返ってくることがあります（そのファイルの解凍時に必ずそうなるわけでもない）。

HARC hArc = SevenZipOpenArchive(NULL, [filePath], M_CHECK_ALL_PATH or M_CHECK_FILENAME_ONLY);

●前にもありましたが、時々、llWriteSizeが全解凍サイズ一歩手前で止まってしまうことがあります。

●条件はよく分かりませんが、以前お渡しした「interruptionTest.7z」などで一部解凍を中断をした場合、
３秒位待たされるようになりました。
なお、全部解凍の中断の場合は待たされることはないようです。

お手数をおかけします…。
580：x@rgs★：2020/06/27(土) 00:59:44 ID:???0: >>579

確認ありがとうございます。
どの不具合も当方の環境では再現できなかったため、あまり対応できていません…

>●解凍中断→即別アーカイブ解凍などを繰り返していると、
>時々、以下のhArcにnullptrが返ってくることがあります（そのファイルの解凍時に必ずそうなるわけでもない）。
直後にSevenZipGetLastError()を呼ぶとどのような値を返しますか。

>●前にもありましたが、時々、llWriteSizeが全解凍サイズ一歩手前で止まってしまうことがあります。
変数の初期化タイミングを変更してみました。

>●条件はよく分かりませんが、以前お渡しした「interruptionTest.7z」などで一部解凍を中断をした場合、
>３秒位待たされるようになりました。
>なお、全部解凍の中断の場合は待たされることはないようです。
不具合発生時のコマンド引数や処理中ファイル、llWriteFileの値は分かりますか。
スキップファイルの情報送信ができていなかった不具合は修正しました…があまり関係なさそうです。
581：tenteko：2020/06/27(土) 23:01:30 ID:BrCfT3Wc0: こんにちは。
中断処理については直ったようなのですが（ありがとうございます）、
その他については改善ならず、という感じでした。

以下、報告です。

>>●解凍中断→即別アーカイブ解凍などを繰り返していると、
>>時々、以下のhArcにnullptrが返ってくることがあります（そのファイルの解凍時に必ずそうなるわけでもない）。
>直後にSevenZipGetLastError()を呼ぶとどのような値を返しますか。

次のようなコードで試してみたところ、error には 0 が、value には 33026 が入っていました。

auto hArc = SevenZipOpenArchive(NULL, [filePath], M_CHECK_ALL_PATH);
if (hArc == nullptr) {
DWORD error;
int32 value = SevenZipGetLastError(&error);
}

>>●前にもありましたが、時々、llWriteSizeが全解凍サイズ一歩手前で止まってしまうことがあります。
>変数の初期化タイミングを変更してみました。

こちらは変化なく、やはり一歩手前で止まることがあります。

>>●条件はよく分かりませんが、以前お渡しした「interruptionTest.7z」などで一部解凍を中断をした場合、
>>３秒位待たされるようになりました。
>>なお、全部解凍の中断の場合は待たされることはないようです。
>不具合発生時のコマンド引数や処理中ファイル、llWriteFileの値は分かりますか。
>スキップファイルの情報送信ができていなかった不具合は修正しました…があまり関係なさそうです。

こちらの方は修正成功のようで、無事即座に中断されるようになりました。
582：tenteko：2020/06/27(土) 23:09:15 ID:BrCfT3Wc0: すみません、続きがあるのですが、なぜかNGワードに引っかかるようで投稿できませんでした…。

要点としましては、前回のバージョンで各種値を調べてみた結果、
interruptionTest.7zの一部解凍（最初に見つけた画像の解凍）の最中に中断したときに（中断後１～２秒後くらい？）、
中断が完了するまでの間、コールバック関数で受信したメッセージは _nState == 6 (ARCEXTRACT_PREPARE) だけでした。
その時のファイル名は"interruptionTest\\dummy_file02.rar"です。
なお、コマンドラインは以前にお知らせしたものと変わりません。
583：x@rgs★：2020/06/28(日) 21:54:50 ID:???0: >>581-582

OpenArchive()は原因が分からないため、デバッグ用メッセージを追加しました。
内部のOpenCheck()で例外をcatchするとメッセージを表示します。全てに対応している訳ではないためちょとあやしいです。

>>llWriteSizeが全解凍サイズ一歩手前で止まってしまう
パイプ読み込みスレッドの処理を変更しました。
SevenZip()が正常終了した場合は読み込みが全て終了するまでループするようにしています。

よろしくお願いいたします。
584：tenteko：2020/07/06(月) 20:46:07 ID:BrCfT3Wc0: こんにちは。

前回、デバグ用メッセージを追加していただいたのですが、
幸か不幸か、SevenZipOpenArchive()がエラーを出さなくなってしまいまして…。
この部分については調査できずじまいとなりました。

他方、時々llWriteSizeが全解凍サイズ一歩手前で止まってしまう現象については
継続して発生しており、引き続き対処が必要なようです。

宜しくおねがいします。
585：x@rgs★：2020/07/07(火) 20:15:32 ID:???0: >>584

投稿ありがとうございます。
>>548の処理の処理を取り入れてみました。
ご確認ください。
586：tenteko：2020/07/18(土) 20:08:42 ID:nzIvPxNw0: こんにちは。
遅くなってしまいました。

しばらくテストをやってみた結果なのですが、以下の不具合が発生しておりました。

・SevenZipOpenArchive()が再びnullptrを返すようになってしまった。
・時々llWriteSizeが全解凍サイズ一歩手前で止まってしまうことがある。

中々難しいですね…。
587：x@rgs★：2020/07/20(月) 07:53:54 ID:???0: >>586

お世話になっております。
毎度毎度すみません。

>・時々llWriteSizeが全解凍サイズ一歩手前で止まってしまうことがある。
前回削除した処理を再度実装しました。
これで上手くいかないとなると、なかなか難しいです。

>・SevenZipOpenArchive()が再びnullptrを返すようになってしまった。
当方の環境では再現できないため、誠に申し訳ないのですがtenteko様の環境でデバッグをお願いできますでしょうか…
今回の書庫にソースファイルを同梱していますので、
1.7-zipのソースコードを展開。
2.7-zip32.dll(公式)のソースコードを展開。
3.7z1900002_ungarbled(今回)のソースコードを展開。
でビルドできます。
MyOpenArchive.cppのCOpenArchive::Open()内、
438行目か446行目のg_StdOut.SetLastError(res)でエラー値(ERROR_FATAL=0x8102=33026)がセットされているはずです。
お手数をおかけいたしますが、よろしくお願いいたします。
588：tenteko：2020/08/03(月) 21:36:08 ID:nzIvPxNw0: こんにちは。

折角ソースコードまで用意していただいて恐縮なのですが、
私の方でデバッグするのは、今の知識と技術力では難しそうです…すみません。

そこで一つ提案なのですが、今の所、「7z1900002_ungarbled_debug200504」版が
最も堅牢・安定しているように思います。
こちらのバージョンでひとまず安定版としてみられてはいかがでしょうか。
589：x@rgs★：2020/08/11(火) 07:01:06 ID:???0: >>588

投稿ありがとうございます。
無理を言って申し訳ございませんでした。

debug200504をベースに、以後の不具合修正を取り込んだものをリリースというかたちにしたいと思います。
引き続きよろしくお願いします。
590：x@rgs★：2020/08/17(月) 22:02:34 ID:???0: >>588-589

debug200504ベースの人柱版を公開しました。
問題がなければこのままリリースしたいと思います。
591：x@rgs★：2020/08/22(土) 22:40:24 ID:???0: >>588-590

Ver.19.00.00.02を公開しました。
592：kiyohiro：2020/08/23(日) 13:23:02 ID:OgaZs.BA0: どうもお世話になってます
Tascher 1.63
ですが
WinXp未対応ですか？
以下のウィンドウが出て起動出来ませんでした
---
Tascher.exe - コンポーネントが見つかりません
PROPSYS.dll が見つからなかったため、このアプリケーションを開始できませんでした。アプリケーションをインストールし直すとこの問題は解決される場合があります。
---
未対応の場合旧バージョンを使わせていただくので構わないのですが
Readme.txt
【動作環境】　Windows XP以降
とあるのでバグの可能性もと思いまして報告します

また、上書きしてしまったので
XP対応の旧バージョン(Tascher162.zip)をダウンロード出来るようにお願い出来ますか？
よろしくお願いします
593：x@rgs★：2020/08/25(火) 01:12:14 ID:???0: >>592

いつもお世話になっています。
一応はXP対応です。
起動できなかった原因はPropVariantToString()で、この関数はXP SP2以降であれば対応していますが、Windows Desktop Search(WDS) 3.0以上が必要です。
既にWDS 3.0は公開されていないようなので、動的リンクした人柱版を公開しました。
お試しください。
594：kiyohiro：2020/08/25(火) 15:24:28 ID:OgaZs.BA0: >>593
対応ありがとうございます
XP環境で動作確認しました
595：kiyohiro：2020/08/25(火) 16:26:49 ID:OgaZs.BA0: >>594
Microsoft®Update カタログ
でWDSを検索すると
Windows XP 用 Windows サーチ 4.0 (KB940157)
を見つけたのでインストールすると
Tascher 1.63
も動きました
596：x@rgs★：2020/08/26(水) 07:20:42 ID:???0: >>594-595

報告ありがとうございます。
無事動作したようで何よりです。
597：通りすがりの人：2021/11/20(土) 14:57:21 ID:/A6T.bsU0: archer

要望：予め除外するウィンドウ（exe）を指定したい。

マルチウィンドウでの利用で、いくつかのソフトやウィンドウは常に表示してあるためスイッチに表示あると煩わしい。

--
gui4recesの作者さんだとは知らず、毎日使っております！ありがたやm(_ _)m
598：x@rgs★：2021/11/21(日) 21:28:42 ID:???0: >>597

投稿ありがとうございます。
archerとのことですが、当該ソフトは公開を停止しています。
Tascherのことでしたら、[高度な設定]-[フィルタ]-[除外するファイル名]で指定することができます。
よろしくお願いします。
599：597：2021/11/22(月) 04:02:24 ID:3ZXq2teU0: 作者様、ご返信ありがとうございます。

Tascherでした。
設定の意味を誤解しておりましたが、無事希望が叶いました。ありがとうございますm(_ _)m
600：x@rgs★：2021/11/22(月) 07:14:49 ID:???0: >>599

分かりにくい設定ですみません。
解決したようで何よりです。
601：597：2021/11/22(月) 12:26:18 ID:zGZwmaUU0: 度々失礼いたします。

標準Alt+Tabと置き換えるべく、置き換え設定例はありますでしょうか？
Tascher表示にAlt+Tab指定すると「ホットキーの登録に失敗しました」と出ますが、とりあえず表示は別ソフトAutoHotKeyでなんとか解決。
「Alt押しながら」の挙動をシートカットに指定できず困っておりました。
602：x@rgs★：2021/11/22(月) 22:08:41 ID:???0: >>601

Tascher単独ではAlt+TabやWin+Tabを置き換えることは現在できません。
AutoHotKeyとの組み合わせ、例えば、
1.Tascherの[設定]-[表示(Alt+Tab風)]で、[次のアイテムを選択]を「Alt+[」、[前のアイテムを選択]を「Shift+Alt+[」に設定。
2.AutoHotKeyで「!Tab::![」
で表示できるかと思います。
#表示(Alt+Tab風)設定は現在公開中の人柱版から実装された機能です。

よろしくお願いします。
603：597：2021/11/23(火) 00:45:27 ID:QhptAkeA0: ご丁寧にありがとうございます。

なんと、すでにAlt+Tab風なるものがあったのですね！さっそく試してみますm(_ _)m
604：通りすがりの人：2021/11/30(火) 23:06:20 ID:3TvlCvBc0: いつもありがたくTimeStamp Keeperを使わせてもらってます。
ファイルの誤字を修正する際などにこれがあると大変便利です。

そんな便利なTimeStamp Keeperですが、1点だけ要望があります。
それは「クリア」実行前の確認機能の追加です。

まれにですが「復元」を押すつもりが誤って隣の「クリア」を押してしまい
「あ゛��！！」となる事があるので、
「復元」が押される前に「クリア」が押された場合は
確認ダイアログを出す、的なオプションがあると大変ありがたいです。

ご検討宜しくお願い致します。
605：x@rgs★：2021/12/01(水) 01:18:57 ID:???0: >>604

投稿いただきありがとうございます。
「復元前に確認ダイアログを表示」「クリア前に確認ダイアログを表示」設定を追加してみました。
それぞれ、引数「/cr」「/cc」を付加して起動すると、あらかじめ有効にすることができます。

手抜きのため、ご要望のあった「復元」が押下される前かどうかの判断はしていません…

ttp://frostmoon.sakura.ne.jp/TimeStampKeeper/debug.html

よろしくお願いします。
606：604：2021/12/01(水) 21:49:26 ID:c3ePbgGs0: >>605

迅速なご対応どうもありがとうございます！

早速使わせてもらいましたが、機能としてはこれで十分です。
コマンドライン引数での起動も問題無く動作しております。
これで間違ってクリアしてしまう事も無くなり、
ますますTimeStamp Keeperが使いやすくなりました。

こんなに早く対応して頂けるとは思っておりませんでした。
お忙しい中本当にどうもありがとうございました。
607：x@rgs★：2021/12/01(水) 22:53:19 ID:???0: >>606

無事動作したようで何よりです。
しばらく様子を見てから正式版として公開します。
608：604：2021/12/02(木) 06:09:50 ID:c3ePbgGs0: 承知しました。
もし何かあれば報告します。
609：さすらい猫：2021/12/14(火) 01:34:27 ID:Qu9EAeEo0: 深夜ですがこんばんは
ここんとこで、あぷろだ系のサイトから多量のデータを落として、久々にashleyを使おうとしたのですが…
ファイルはashleyに放り込めるんですがリネーム等の処理がまるでできないことに気が付きました。
旧PCから乗り換えた新PCで処理しようとしたんですが、Win10の最新版ではまだ対応できていない感じでしょうか？
旧PCもWin10でアップデートかけていないので１年前ぐらいのバージョンのままですが、そちらでは正常に処理できました。
ランタイムエラーも出ていないので、ちょっと原因がわからない状態です。

お忙しい中かもしれませんが、対応よろしくお願いいたします。
610：さすらい猫：2021/12/14(火) 23:14:55 ID:Qu9EAeEo0: どうやら、zipファイルの場合はリネームできるのですがrarファイルだけリネームできていないようです。
rarファイルのみなので、自分が使っているwinrar等の解凍する環境の違いかもしれませんが、原因特定には至らない状態です。
611：x@rgs★：2021/12/15(水) 00:43:03 ID:???0: >>609-610

投稿ありがとうございます。
最新版のUnRAR.dll(Ver.6.10.3.343)で確認してみましたが、
通常のRAR書庫であれば内部のフォルダ名やサムネイルの取得ができました。
件の書庫ファイルがさすらい猫さまの旧PCで処理できるようであれば、
一度新PCで最新版のUnRAR.dllを導入いただき、お試しください。
612：さすらい猫：2021/12/15(水) 02:52:16 ID:Qu9EAeEo0: >>x@rgs★さま

UnRAR.dllの最新版をAshleyのフォルダに入れて試してみたら、問題なくリネームできるようになりました！
早速の対応、ありがとうございます！
今までの旧PCの方でもWinRARを使ってたのですが、UnRAR.dllをAshleyフォルダに入れなくてもリネームできてたんで、気が付きませんでした(;^ω^)

このAshleyに成り代わるアプリは他にないので、とても重宝しています。
これからもどんどん使っていこうと思います！本当にありがとうございます！
613：x@rgs★：2021/12/15(水) 20:06:51 ID:???0: >>612

解決したようで何よりです。
また何かありましたら、お気軽にお知らせください。
614：kiyohiro：2021/12/31(金) 17:09:43 ID:gnMqvq6g0: どうもお世話になってます
7-Zip-zstd ｈｔｔｐｓ：／／github.com/mcmilk/7-Zip-zstd
を見つけこれの7z.dllを使い最近たまにもらうTest.tar.zstを
reces&ax7z.spi&7z.dll(/Ds"D:\Software (x86)\reces\spi" /me /c2 /ct /qe)
で解凍出来ないかと試しましたが
サイズ0のTest.tarが解凍されダメでした
2重の拡張子がダメなのかと思いましたが
Test.tar.gzはtar32.dllでですが問題無いですし行き詰まりました
単にオプションが間違ってるのでしょうか？
すいませんがアドバイスもらえないでしょうか？
ちなみに
画像ビューアなどではax7z.spi&7z.dllで中身を表示出来ました
ax7z.spi.iniもzst=1になってます
あと
7-Zip-zstd対応の
7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版
は出来ないでしょうか
よろしくお願いします
615：x@rgs★：2021/12/31(金) 23:29:27 ID:???0: >>614

ご報告いただきありがとうございます。
人柱版を公開いたしましたので、ご確認ください。
616：kiyohiro：2022/01/01(土) 13:00:01 ID:gnMqvq6g0: >>615
修正ありがとうございます
解凍出来るようになりました
ただ、Test.tar.zstでTest.tarが解凍されもう一度解凍が必要になるので
出来ればTest.tar.gzのtar32.dllの解凍の様に2重の拡張子一気に解凍出来ないでしょうか?
zstは使いづらいので7zに再圧縮(Ds"D:\Software (x86)\reces\spi" /mr7z /lx /e /t)
などしたいのでよろしくおねがいします
あとWin10x64環境ですが
/Ds"D:\Software (x86)\reces\spi"
の様にパスを""でくくらないと認識しないのですね
WinXpは無しでもパスが通るので気付くのに時間がかかりました
こちらはReadme.txtの説明がなかったので報告だけしときます
617：x@rgs★：2022/01/01(土) 23:50:27 ID:???0: >>616

動作したようで何よりです。
7-Zipでtar.zstが一度に解凍できないのは仕様です。
tar.gzやtar.bz2も同様で、7-Zipで解凍させるには、パイプを使うかバッチを書くことになると思います。
もしかしたら、xzの時のように、zstdに対応したtar32.dllを誰かが開発するかもしれません。

/Dsオプションの件、パスにスペースがある場合は二重引用符で囲む必要があります。
これは/Dsオプションに限らず、他のオプションや入力ファイルも同様です。
618：kiyohiro：2022/01/03(月) 14:36:06 ID:gnMqvq6g0: >>617
> 7-Zipでtar.zstが一度に解凍できないのは仕様です。
分かりました
> もしかしたら、xzの時のように、zstdに対応したtar32.dllを誰かが開発するかもしれません。
7-Zip-zstdのCodecs-x32.7zのzstd-x32.dllや別に見つけたzstd.dllで
/ms[library][:prefix]
で解凍出来ないか試しましたがよくわからず
ファイラーやランチャーに登録してるのでそれほどてまでもないですし
結局1つずつ順番に解凍するのが早いですね
今回も色々ありがとうございました。
619：通りすがりの人：2022/01/30(日) 09:06:00 ID:OmOSGxQU0: Susieプラグインのdllとして使用。
ax7z_s.spi （ax7z-0.7-457s_y4b5.zip）から
7z1900001_ungarbledを使っていた。
久しぶりに更新したら、
7z1900001_ungarbledでは、rar書庫は開けたが、
7z2106001_ungarbledでは、rar書庫は開けなかった。
報告まで。
620：x@rgs★：2022/01/30(日) 10:41:31 ID:???0: >>619

報告いただきありがとうございます。
確認したところ、手元の環境では無事動作しました。
うまくファイルを配置できているか、念のためご確認いただけますでしょうか。
621：kiyohiro：2022/02/22(火) 18:58:54 ID:bGQIxGGM0: どうもお世話になってます
ライブラリ指定の
例　/me7-zip32
ですが
Spi(ax7z.spi)の指定はどうするのでしょうか?
または出来ないでしょうか?
622：x@rgs★：2022/02/23(水) 01:13:40 ID:???0: >>621

毎度ありがとうございます。
解凍であれば、「/meax7z.spi」で指定できます。
もし、「対応していない圧縮形式かファイルが壊れています。」とエラーが出た場合は、
「7z.dll」が存在するか確認してください。
「ax7z.spi」と同じ階層か、7-Zipがインストールされたディレクトリから読み込む仕様のようです。
「ax7z.spi」と同じ階層に「7z.dll」をコピーする方が楽かもしれません。
623：kiyohiro：2022/02/23(水) 05:25:34 ID:bGQIxGGM0: > 622
回答ありがとうございます
/meax7z.spi
で指定解凍出来ました

それで
画像ビューアのax7z.spi＋7z.dllで文字化け
の原因の特定が出来ました

recesではtar32.dllで解凍されるので気づきませんでしたが
7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版 v21.06.00.01の
7-zip32.dll
と
ax7z.spi＋7z.dll
.tarで圧縮したShift-JIFのテキストの
解凍ですが文字化けするみたいです
624：通りすがりの人：2022/02/23(水) 16:51:04 ID:E070r8vg0: 別の者です。文字化け再現しました。
昔のzipですが、MINT310.ZIPの中のmint-3.10/madoka/でぢかめ整理.misが文字化けします。
本家7-Zipの21.07 21.06でも文字化けし、19.00では文字化け無しなので19.00系の7-zip64.dllを利用して回避してます。
625：x@rgs★：2022/02/23(水) 18:38:47 ID:???0: >>623
>>624

ご報告ありがとうございます。
文字化け確認できました。
21.02の仕様変更が原因のようです。

21.07にも追い付けておらず、更新停滞気味ですが、
対応予定ですのでしばらくお待ちください。
626：kiyohiro：2022/02/23(水) 19:04:19 ID:bGQIxGGM0: >>625
回答ありがとうございます
もう一つ質問お願いします
同じオプションとspiパスでspiフォルダにUNBYPASSも入れましたが
x64版recesの方だけ解凍出来無いです
Win10x64環境

x86版は問題なく解凍出来ました
/Ds"D:\Software (x86)\reces\spi" /meax7z.spi /c2 /ct /qe /q0

x64版はエラー(ライブラリax7z.spiの読み込み失敗しました)
/Ds"D:\Software (x86)\reces\spi" /meax7z.spi /c2 /ct /qe /q0

UNBYPASSは入ってます
D:\Software (x86)\reces\reces.exe
D:\Software (x86)\reces\x64\reces.exe
D:\Software (x86)\reces\x64\UNBYPASS.DLL
D:\Software (x86)\reces\x64\UNBYPASS.EXE
D:\Software (x86)\reces\spi\UNBYPASS.EXE
D:\Software (x86)\reces\spi\ZBYPASSA.SPH
D:\Software (x86)\reces\spi\ZBYPASSI.SPH
D:\Software (x86)\reces\spi\7z.dll(x86とx64入れ替えて両方試しました)
D:\Software (x86)\reces\spi\ax7z.spi
627：x@rgs★：2022/02/24(木) 23:50:27 ID:???0: >>626

x64版の場合は、ax7z.spiではなく、ZBYPASSA.SPHを指定することになります。
628：x@rgs★：2022/02/25(金) 07:28:22 ID:???0: 7-Zip 19.00ベースの文字化け対策版の公開を再開しました。
今回の問題は本家でも報告されていますので、次バージョンで修正されるかもしれません。
629：kiyohiro：2022/02/25(金) 16:01:30 ID:bGQIxGGM0: >>627
回答ありがとうございます
/Ds"D:\Software (x86)\reces\spi" /meZBYPASSA.SPH /c2 /ct /qe /q0
でもダメでした
一応画像です
ｈｔｔｐｓ：／／imgur.com/PdZpaGk
630：x@rgs★：2022/02/28(月) 07:33:04 ID:???0: >>629

確認いただきありがとうございます。
ax7z.spiの場合、たしかに動作しませんね。
axzip.spiであればうまく動作しましたので、
少し原因を調べてみます。
631：x@rgs★：2022/04/08(金) 23:26:03 ID:???0: >>629-630

遅くなりましたが、不具合を修正した人柱版を公開しましたので、ご確認ください。
632：kiyohiro：2022/04/09(土) 05:54:45 ID:ovUvUBZ60: >>631
対応ありがとうございます
今夜勤でwin10x64環境ではまだ確認できてませんが
取り敢えずwinxp環境でエラーがでて使えないようです
---
reces.exe - エントリポイントが見つかりません
プロシージャエントリポイント InitializeCriticalSectionEx がダイナミックリンクライブラリ KERNEL32.dll から見つかりませんでした。
---
よろしくお願いします
633：x@rgs★：2022/04/09(土) 07:59:48 ID:???0: >>632

毎度ありがとうございます。
32bit版のプラットフォームツールセットを「Visual Studio 2017 - Windows XP (v141_xp)」から「Visual Studio 2015 - Windows XP (v140_xp)」に変更しました。
ご確認ください。
(64bit版は変更なしです。)
634：kiyohiro：2022/04/09(土) 13:38:37 ID:ovUvUBZ60: >>633
対応ありがとうございます
winxp環境での動作
win10x64でのZBYPASSA.SPH&az7z.spiで解凍
確認しました
ただ、
Ds"D:\Software (x86)\reces\spi" /meZBYPASSA.SPH /c2 /ct /qe /q0
で
空フォルダの解凍
と
/c2 /ctオプション
が出来ないようです
635：kiyohiro：2022/04/12(火) 16:48:48 ID:ovUvUBZ60: どうもお世話になってます
7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版
某ソフトで旧バージョンを使いたいです
残ってましたらVer.17.01.00.01 - 2017/08/29 zip版
再公開お願いします

> ファイルやフォルダが表示されない場合は使用している「dll」のバージョンによります。
> 動作を確認している「7z」の「dll」は以下です。
> ○Ver.17.01.00.01 - 2017/08/29
> ・7-Zip 17.01 betaをベースにビルド。
636：x@rgs★：2022/04/12(火) 20:31:21 ID:???0: >>634-635

空フォルダの解凍は、今のところax7z.spiは対応していないようです。

/c2や/ctの動作は当方の環境では確認できました。
もし動作しないようであれば、お手数ですが書庫を送付いただけますでしょうか。

17.01 betaベースのバージョンは下記からダウンロードできます。
ttp://frostmoon.sakura.ne.jp/dlcnt/download.php?download=7z1701001_ungarbled
637：kiyohiro：2022/04/13(水) 13:14:21 ID:ovUvUBZ60: >>636
再公開ありがとうございます
通常の解凍では問題なかったのでバージョンアップしてましたが
19.00.00.03
21.06.00.01
では
書庫内操作で空フォルダの表示＆解凍が出来ない様になってたので
助かりました

> 空フォルダの解凍は、今のところax7z.spiは対応していないようです。
分かりました

> /c2や/ctの動作は当方の環境では確認できました。
空フォルダがあるとダメだったようです
これもax7z.spiの関係みたいですね
以下の様になりました

1.7z
書庫内
1\
2\てすと.txt
3\
解凍
2\てすと.txt

2.7z
書庫内
1\てすと.txt
2\てすと.txt
3\てすと.txt
解凍
2\1\てすと.txt
2\2\てすと.txt
2\3\てすと.txt

あと
tar32.dll/tar64.dll 2.42 rev.7(私家版)
と本家
TAR32.DLL 2.43
がバージョンアップしてました
軽く試しただけですがrecesで問題なく動作しました
638：x@rgs★：2022/04/14(木) 00:39:01 ID:???0: >>637

>書庫内操作で空フォルダの表示＆解凍が出来ない様になって
21.06.00.01で試してみましたが、手元の書庫では無事解凍できました。
どのような書庫でも、空ディレクトリの解凍はできませんか。

>tar32.dll/tar64.dll 2.42 rev.7(私家版)
ご報告ありがとうございました。
639：Kiyohiro：2022/04/14(木) 04:56:10 ID:ovUvUBZ60: >>638
すいません説明不足でした
recesのことではなく>>635の某ソフトのことです
640：x@rgs★：2022/04/14(木) 07:17:20 ID:???0: >>639

動作が少し気になりますので、差し支えなければソフト名を教えていただけませんか。
(メールでもかまいません。)

よろしくお願いします。
641：Kiyohiro：2022/04/14(木) 11:21:33 ID:ovUvUBZ60: >>640
どうもお世話になってます
最初メールしましたがGメールでexeが含まれてるので
エラーでしたがもしかしたら行ってるかもです

ソフトはannsFMarchiveです
以前相談したソフトで今度は空フォルダでした
> annsFMarchiveで一部ファイルが表示出来なくなった件
> これは、
> Ver10.13 2021-02-03のバイナリだと拡張子なしのファイルが表示されないこ
> と
> を確認しました。

以下の様な書庫
---
1.7z&1.zip
中身
1\てすと.txt
2\
a\てすと.txt
a.a\てすと.txt
---
で
2\
a\てすと.txt
が表示されませんでした

ただ、あの後対応して頂いて現在修正されてます
最新はannsFMarchive v10.43
ttps://www.bonsfm.com/annsfmwindows/annsfmarchivewin

メニュー→ファイルの
「7z の通常書庫をテキスト形式で取得」
「7z の自己解凍書庫をテキスト型式で取得」
「Zip の通常書庫をテキスト形式で取得」
「Zip の自己解凍書庫をテキスト型式で取得」
チェックを外す
メニュー→設定→アーカイブパラメータ設定
解凍用ZipDLL選択→7-zip32.dll

で以前の仕様に戻り再現出来ると思います
完全戻るかは分かりません
642：Kiyohiro：2022/04/14(木) 13:49:26 ID:ovUvUBZ60: >>641
追記
サブで使ってるファイラーでも
7-zip32.dllでの空フォルダの表示同様でした
Double Window(v2022年02月22日)
ttp://www.st.sakura.ne.jp/~higashi/
643：通りすがりの人：2022/05/01(日) 20:48:28 ID:SE3aXeWs0: こんばんは。

こちらに投稿してよいのかわからなかったのですが、久々に7-zip系の文字化け対策版DLLをダウンロードしようと「Frost Moon Project」のトップページ

ttp://frostmoon.sakura.ne.jp/

にアクセスしたのですが、レンタルサーバーのデフォルトページみたいなのが表示されて、ダウンロードできなくなっているようです。
配布を終了されてしまったのでしょうか。
それとも他のページへ移転したのでしょうか。

以上、よろしくお願いいたします。
644：通りすがりの人：2022/05/06(金) 19:17:27 ID:eG/vWEu60: こんばんは。

>>643 に投稿したものです。

すみません、この件ですが、結論からいうと解決しました。
こちらのブラウザの設定でhttpをhttpsに自動的にリダイレクトするようにしていたのですが、これが原因だったようです。
この設定で同じ「sakura.ne.jp」のアドレスでも問題ないサイトがあったので、原因を思いつくのにかなり時間を要してしまいました。
ご迷惑をおかけしました。

それでは。
645：x@rgs★：2022/05/06(金) 23:00:12 ID:???0: >>642
ご報告ありがとうございます。
確認してみます。

>>643-644
すみません。当サイトは未だに常時SSL化できていません。
646：Kiyohiro：2022/05/07(土) 05:53:21 ID:ovUvUBZ60: >>645
両ソフト共、不具合報告し
現在空フォルダ表示出来るように修正されました