ソフトウェアに関する不具合、要望、感想 - 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書庫を選択しようとしても不可]
・要望、感想については、ご自由にどうぞ。
479：x@rgs★：2017/09/17(日) 00:41:00 ID:???0: >>477-478

>パスワード付7z自己解凍書庫とヘッダ暗号化書庫7z自己解凍書庫
>も
>Cab圧縮も
無事動作したようで何よりです。

>ちなみに7zの圧縮率の変更は7-zipCMD.txtを見ると[0|1|3|5|7|9]になってますが
>7zのrecesの/lオプションも奇数だけですか？
recesの「/l」は続けて指定された数字をライブラリに投げるだけですので、奇数偶数問いません。

>Cab圧縮のアプリケーションエラーの件
対象ファイルが7バイトもしくは8バイトの場合、アプリケーションエラーが発生するようです。
追加で「-mz」を指定するとエラーなく処理されました。
#/q0 /mscab32:Cab -a -mz I:\テスト\test.cab D:\Test\ てすと.txt
#でお試しくださいませ。
480：kiyohiro：2017/09/17(日) 06:37:40 ID:sgNgRABQ0: >>479
回答ありがとうございます
-mz追加で圧縮出来ました
これで全て解決しましたありがとうございました

それとすでに記入があったらスイマセンが
Cab圧縮や自己解凍書庫とかはめったに無く忘れる可能性もあるので
お手数ですが何時でもかまいませんので次回バージョンアップ時にも
今回の質問をReadme.txtに例として追加していただけると助かります
よろしくお願いします
481：x@rgs★：2017/09/18(月) 00:24:23 ID:???0: >>480

報告ありがとうございます。
私も忘れそうなのでReadme.txtに追記しておきます。

ほかに不具合・要望がありましたら是非々々お知らせくださいませ。
482：x@rgs★：2017/10/26(木) 22:43:06 ID:???0: ttp://jbbs.shitaraba.net/bbs/read.cgi/computer/42633/1272626885/15-16

のつづき。

とりあえず、要望のあった機能の実装だけはしてみましたのでご確認ください。
マルチモニター環境がないため、動作は確認できていませんのでご注意ください。

ttp://www16.atpages.jp/rayna/Tascher/debug.html

ほかにマルチモニター絡みでの要望や、その他ご意見ありましたら、是非是非投稿をお願いします。
483：razgriz13：2017/10/29(日) 19:42:06 ID:hlTGz1T.0: >> 482

早速のご対応、誠にありがとうございます。

早速、試してみました。

・・・・・が、まるで機能しません。
アプリは起動します。（初回起動時、OSのアプリ保護が出ましたが。）

キーボードショーカットからの呼び出しや、システムトレイのアイコンから設定
画面を開いたり、、、何かすると、強制終了します（アプリが）。

OSのイベントログでもWindows Error Reportingが挙がってきます。
～～～
障害バケット 120863262764、種類 4
イベント名: APPCRASH
応答: 使用不可
Cab ID: 0

問題の署名:
P1: Tascher.exe
P2: 1.6.3.0
P3: 59f589d3
P4: Tascher.exe
P5: 1.6.3.0
P6: 59f589d3
P7: c000041d
P8: 0000000000005157
P9:
P10:
～～～～

使っているOSは、
　Windows10 ６４ビット　Pro　
　バージョン　１７０３　
　ビルド　１５０６３．６７４

デバッグに向けて何か必要な情報があれば、コメント願います。
484：x@rgs★：2017/10/29(日) 21:31:59 ID:???0: >>483

返信ありがとうございます。
何度も申し訳ないです。再度修正版に差し替えましたのでご確認ください。
485：razgriz13：2017/11/08(水) 21:00:28 ID:hlTGz1T.0: >>484

返信遅くなり、申し訳ありません。
（勝手に、新規投稿は、メール通知されると思っていました。。）

動作確認の結果、プライマリー側のモニター上では、通常通り
期待した動きをします。

ただし、セカンダリー側のモニター上では、異常停止します。
メニューがポップアップしないと思ったら・・・フッとシステムトレイから
消えて無くなります。
OSイベントログでは、前回同様のメッセージが記録されます。

デバッグログなど、何か解析に役立つ情報が必要でしたら
ご連絡ください。

よろしくお願いします。
486：x@rgs★：2017/11/10(金) 01:34:25 ID:???0: >>485

返信ありがとうございます。
投稿のメール通知は下記URLより可能です。
ttp://jbbs.shitaraba.net/bbs/notice_mail.cgi/computer/42633/

動作確認何度も申し訳ありません。
仮想PC(Win7)では動作したので、てっきり修正されたものとばかり思っておりました。
Win10ではタスクバーが全てのモニタに表示可能だったりと、仕様が異なるので今のところ原因は分かりません。

下記はマルチモニタ対応のために追記した処理の一部を抜粋したものです。
カーソルをプライマリおよびセカンダリに置いて起動しても、正常に動作するか確認をお願いできませんか。
ttp://www16.atpages.jp/rayna/Tascher/monchk.zip
よろしくお願いします。
487：razgriz13：2017/11/19(日) 19:22:45 ID:hlTGz1T.0: >>486

ご連絡、並びにご対応いただきまして、ありがとうございます。
また、こちらからのご連絡ができておらず、申し訳ございません。

１８日版の修正モジュールにて、当方の環境でも動作致しました。
（前回までのような異常終了の症状は、再現しませんでした。）

しばらくこのまま、使ってみたいと思います。
進展ありましたら、また書き込み致します。
488：通りすがりの人：2018/01/11(木) 01:00:39 ID:SIodCj0A0: 7-Zip 18.00 betaが公開されました
489：x@rgs★：2018/01/11(木) 06:13:46 ID:???0: >>488

ご報告ありがとうございます。
近日中に公開予定です。
490：通りすがりの人：2018/01/13(土) 18:41:09 ID:odSgo6dA0: 7z18000001_ungarbled.zip
gui4reces + 7z.dll対応版7-zip64.dllで動作しました
491：x@rgs★：2018/01/14(日) 00:21:32 ID:???0: >>490

ご報告ありがとうございます。
とくに問題はないようで何よりです。
492：通りすがりの人：2018/01/30(火) 15:57:06 ID:zKDatD9s0: 7-Zip 18.01
正式版がReleaseされました
493：x@rgs★：2018/01/30(火) 20:57:17 ID:???0: >>492

ご報告ありがとうございます。
7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版 Ver.18.01.00.01を公開しましたのでご確認ください。
494：通りすがりの人：2018/01/30(火) 23:01:38 ID:nwipGVeA0: Ver.18.01.00.01
gui4reces + 7z.dll対応版7-zip64.dll
動作しました
495：x@rgs★：2018/01/31(水) 21:22:08 ID:???0: >>494

ご報告ありがとうございます。
問題はとくにないようで何よりです。
496：通りすがりの人：2018/05/01(火) 17:54:41 ID:5PQzfMrI0: 7-Zip 18.05
出ました
497：通りすがりの人：2018/05/01(火) 19:29:49 ID:5PQzfMrI0: 7-Zip 18.05、Bug関連なのか、引っ込められました。
しばらく様子見です
498：通りすがりの人：2018/05/01(火) 19:31:08 ID:5PQzfMrI0: と思ったらやっぱり公開されてました。すみません・・・
499：x@rgs★：2018/05/02(水) 00:30:53 ID:???0: >>496-498

ご報告ありがとうございます。
一部仕様変更に対応するため、公開まで少々お時間をいただきます。
しばらくお待ちくださいませ。
500：通りすがりの人：2018/05/08(火) 07:43:38 ID:kSvvbG6E0: 18.05更新、7z対応版で特に問題無く動作してます
501：x@rgs★：2018/05/08(火) 22:03:24 ID:???0: >>500

ご報告ありがとうございます。
問題はとくにないようで何よりです。
502：須藤幸一：2018/07/04(水) 21:11:50 ID:vdkKBWX.0: 【OS】Windows 8.1/ 10
【ソフト名】7-zip32.dll/7z.dll対応版
【バージョン】Ver.18.05.00.01
【症状】既存の同名ファイルがあるディレクトリにCHM等を解凍するとエラー
【再現手順】
コマンド例: x D:\Hoge.chm -oD:\Test\ -scsUTF-8
・空の指定ディレクトリにCHMファイルを解凍した場合は正常。
・ディレクトリ内に同名ファイルが一つでもあると解凍処理の途中でエラー。
例外 #C0000005 (access violation at ～: read of address 0x00000000)
・上書確認が出る前にエラーになっているようです。
・これによって呼び出し側アプリケーションも異常終了してしまいます。
・CHM 以外に、MSI を解凍した場合にもエラーになります。
・すべての形式は試していませんが、ZIP、7z、RAR、ISO などでは問題ありません。

アーカイバDLLは、NyanFi という2画面ファイラーで利用させていただいてますが、
解凍のみを行うテストプログラムを作って試しても、エラーが発生します。
503：x@rgs★：2018/07/05(木) 22:53:38 ID:???0: >>502

ご報告ありがとうございます。
不具合を確認しました。

しばらく開発環境が手元にないため、
修正版公開までしばらくお待ちください。
504：kiyohiro：2018/07/07(土) 12:40:03 ID:/CQ6kTUM0: どうもお世話になってます
解凍や書庫のテストでErrorメッセージが出るのですがこれは何のエラーなんでしょうか？
一応、解凍は問題無く出来てます
また、Explzhの書庫のテストではエラーは出なかったです

試したソフト
リサイズ超簡単！Pro v4.07 ttp://my.reset.jp/~triton/ (Vectorからのダウンロード)
そのままではwinxpで自己解凍出来ないけど中身はwinxpで使えるのでrecesで解凍しました

Errorメッセージは以下です
よろしくお願いします

7-Zip (a) 18.05 + ungarbled patch (x86) : Copyright (c) 1999-2018 Igor Pavlov : 2018-04-30

Testing archive:
D:\Test\RCKP407.exe

ERRORS:
Can't open volume: untitled.cab

--
Path = D:\Test\RCKP407.exe
Type = Cab
ERROR = Can't open volume: untitled.cab
Offset = 844795
Physical Size = 54734
Method = LZX:21
Blocks = 1
Volumes = 1
Volume Index = 0
ID = 12345

Archives with Errors: 1

Open Errors: 1
505：x@rgs★：2018/07/16(月) 22:29:01 ID:???0: >>502

修正版を公開しました。
動作のご確認をお願いいたします。

>>504
「untitled.cab」が含まれていると内部に情報があるものの、
データが壊れているためか、存在しないためか開くことができないようです。
Cab書庫ファイル側の問題と思われます。
506：須藤幸一：2018/07/17(火) 10:19:52 ID:GR8/BufM0: 修正版にて、上書き解凍時の正常動作を確認しました。
どうもありがとうございます。
7z.dll対応版はCHMの内容確認などもできるので重宝しています。
507：通りすがりの人：2018/12/31(月) 12:02:02 ID:MuvB.IPM0: 7-Zip 18.06
公開されました
508：x@rgs★：2018/12/31(月) 18:47:30 ID:???0: >>507

ご報告ありがとうございます。
7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版 Ver.18.06.00.01を公開しましたのでご確認ください。
509：通りすがりの人：2019/01/01(火) 20:35:03 ID:MuvB.IPM0: 7zip対応版、7-ZIP64.DLL ver.18.06.00.01
特に問題無く動作しました
510：通りすがりの人：2019/02/07(木) 16:26:18 ID:QQde9r0A0: 不具合なのかよく判らないですが、気になったので。
【OS】[Windows 10]
【ソフト名】[gui4reces]
【バージョン】[Ver.0.0.1.8]
【症状】[rarのpart書庫を解凍後、処理後削除がpart1ファイルのみ適応される]
【再現手順】
1.「処理後削除＞完全削除にチェック]
2.「rarのpartファイルのpart1を追加し解凍]
3.「マルチボリューム書庫解凍後part1のみ削除され、残りのpartが残る]
何かしら対策を見逃していた場合申し訳ないです
511：x@rgs★：2019/02/08(金) 02:31:40 ID:???0: >>510

ご報告ありがとうございました。
不具合確認いたしました。
7zのような「foo.7z.001」形式なら削除出来ていたのですが、
rarの「foo.part1.rar」形式への対応が出来ていませんでした。

しばらく開発環境が手元にないため、
修正版公開までしばらくお待ちください。
よろしくお願いいたします。
512：x@rgs★：2019/02/17(日) 11:10:07 ID:???0: >>510

お待たせいたしました。
修正版を公開しましたので、ご確認のほどよろしくお願いいたします。
ほかに不具合や要望等ありましたらお気軽にご投稿ください。
513：通りすがりの人：2019/02/18(月) 21:00:54 ID:QQde9r0A0: >>512
確認しました。
part~及び.r00 両形式とも処理後削除されました。
対応有難うございます。
514：通りすがりの人：2019/02/24(日) 14:58:59 ID:B/DF9u7g0: 7-Zip 19.00が公開されているようです。
515：x@rgs★：2019/02/24(日) 21:08:03 ID:???0: >>514

ご報告ありがとうございます。
7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版 Ver.19.00.00.01を公開していますのでご確認ください。
516：通りすがりの人：2019/02/24(日) 21:32:30 ID:B/DF9u7g0: 　ありがとうございます。
　正常に動作することを確認しました。
517：通りすがりの人：2019/03/03(日) 17:53:31 ID:3m.NQLuY0: 【OS】[Windows 10 Pro 1809 x64]
【ソフト名】[gui4reces]
【バージョン】[Ver.0.0.1.8]
【症状】[7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版 Ver.19.00.00.01 を導入すると再圧縮ができない]
【再現手順】
1. 7-zip 19.0(x64)をインストーラでインストール
2. 文字化け対策版7z.dllを7-zipのインストールディレクトリにコピー（上書き）
3. 文字化け対策版7-zip64.dllをgui4recesのインストールディレクトリにコピー（上書き）
4. ファイルをD&Dして再圧縮すると「対応していない圧縮形式かファイルが壊れています。」のエラーが出る
---
ライブラリを読み込んでいます... 7-zip64.dll ver.19.00.00.01
'C:\Users\xxxx\Desktop\7z1900001_ungarbled.zip'を解凍しています...

=> return code 0[0]

7-Zip (a) 19.00 + ungarbled patch (x64) : Copyright (c) 1999-2018 Igor Pavlov : 2018-04-30

Extracting archive:
C:\Users\xxxx\Desktop\7z1900001_ungarbled.zip
--
Path = C:\Users\xxxx\Desktop\7z1900001_ungarbled.zip
Type = zip
Physical Size = 3721350

Everything is Ok

Folders: 2
Files: 9
Size: 8259554
Compressed: 3721350

ライブラリを読み込んでいます...
error: 対応していない圧縮形式かファイルが壊れています。
処理を続行しますか? (Y/N) [Y]:
---
518：517：2019/03/03(日) 17:56:28 ID:3m.NQLuY0: 7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版 Ver.18.06.00.01 では問題なく再圧縮できます
519：x@rgs★：2019/03/03(日) 19:47:58 ID:???0: >>517-518

ご報告ありがとうございます。
この現象は、7-zip 19.00でSetDefaultDllDirectories(LOAD_LIBRARY_SEARCH_SYSTEM32|LOAD_LIBRARY_SEARCH_USER_DIRS)を呼び出すように処理が変更されたことによるものです。
そのため、7-zip32/64.dllがシステムディレクトリに存在しないかつ reces.exe/gui4reces.exeと同じディレクトリに7-zip32/64.dllが存在する場合、
1度目の処理は成功しますが、2度目以降は7-zip32/64.dllの読み込みに失敗してしまいます。
#再圧縮のほか、連続解凍等も同じです。

7-zip32/64.dllをシステムディレクトリに配置し、動作をご確認ください。
よろしくお願いします。
520：517：2019/03/03(日) 23:07:25 ID:3m.NQLuY0: >>519
ありがとうございます。
システムディレクトリに7-zip64.dllを入れることで問題なく動作しました！
521：通りすがりの人：2019/08/17(土) 00:11:13 ID:FzoB9DCw0: 【OS】[Windows 10 1903 64bit]
【ソフト名】[reces 32bit]
【バージョン】[Ver.0.00r34a]
【症状】[/oor 有効時に /d で元ファイルが削除されない]
【再現手順】
[1] test.rar と test.zip を同じフォルダに用意する。
[2] reces.exe /mrzip /oor /d test.rar を実行する。
[3] test_1.zip が作成されるが、元ファイルの test.rar が削除されない。
[4] test.zip が無い状態で[2]を実行すると test.zip が作成され test.rar は削除される。
522：x@rgs★：2019/08/18(日) 05:50:20 ID:???0: >>521

報告ありがとうございます。
不具合を確認いたしました。

修正版公開まで少々お時間をいただきます。
しばらくお待ちくださいませ。
523：x@rgs★：2019/08/18(日) 16:05:23 ID:???0: >>521

お待たせいたしました。
修正版を公開いたしましたので、ご確認のほどよろしくお願いいたします。
524：>>521：2019/08/19(月) 07:18:45 ID:afUr6hAg0: >>523
お疲れ様です。
修正ありがとうございます。
問題なく動作しました！
525：tenteko：2020/01/29(水) 21:27:59 ID:6h5qm12k0: はじめまして。
zipや7z書庫内ファイルを直接読み込める画像ビューワーを作るため、利用させて頂いております。

7-zip32.dll や 7-zip64.dll が通常メモリへの書き出し機能が無いことを知り、途方に暮れていたところ、
こちらの同機能が付いた 7-zip64.dll を偶然知り、とても有難く使わせて頂いております。

ただ、以下の症状が出まして、ちょっと困っております。
対応お願いできますでしょうか。

【OS】[Windows 10 Pro 64bit]
【ソフト名】[7-zip64.dll(7z.dll対応版ではない方)]
【バージョン】[Ver.19.00.00.01]
【症状】[SevenZipExtractMem()で、4,294,967,295バイトを超える書き出しができない]
【再現手順】以下のとおりです。

1.解凍後のサイズが unsigned int32 の上限4,294,967,295バイトを超える書庫ファイル（zipか7z）を用意する。

2.プログラム上で
　　SevenZipExtractMem(NULL, [UTF8のコマンドライン], [書き出し先のバッファへのポインタ], [解凍後の全データサイズ], NULL, NULL, NULL)
　のような感じでバッファへ書き出すようにする。

3.この状態で1.の書庫ファイルを解凍すると、恐らく1.の上限まで書き出したところでプロセスがストップする。

備考：
・SevenZipSetUnicodeMode(TRUE)にしています。
・zipでも7zでも、同じ症状が出ます。
・環境はVS2019、64bitです。
・解凍後のサイズが1.の上限以下（と思われます）だと、正常に解凍できています。
・PCのメモリは32GBです。
526：x@rgs★：2020/01/29(水) 23:22:10 ID:???0: >>525

ご報告ありがとうございます。
不具合確認の上修正いたします。
しばらくお待ちくださいませ。
527：tenteko：2020/01/31(金) 01:17:06 ID:6h5qm12k0: 早速のご返事、ありがとうございます！
対応頂いている最中で申し訳ないのですが、一つ疑問…というか要望があります。

もしかしたら仕様なのかもしれないのですが、SevenZipExtractMem()を実行した際、
コールバック関数（ARCHIVERPROC）に対してメッセージが
ARCEXTRACT_OPEN(3) と ARCEXTRACT_END(2) の２つだけしか送出されておらず、
ARCEXTRACT_BEGIN(0) と ARCEXTRACT_INPROCESS(1) は送出されていないようなのです。
（SevenZip()で解凍した場合は、この４つのメッセージは送出されていました）

ARCEXTRACT_BEGIN(0) と ARCEXTRACT_INPROCESS(1) も送出されるようにして頂けませんでしょうか。
というのは、解凍の途中でどのファイルまで解凍したか知りたいのと、
解凍の途中で解凍を中断したい場合があるためです。
（せめて ARCEXTRACT_BEGIN(0) だけでもあれば助かります）
528：x@rgs★：2020/01/31(金) 07:23:21 ID:???0: >>527

投稿ありがとうございます。
処理中のメッセージも見直してみます。

しばらく手元に開発環境がないため、そこそこお時間いただきます。
申し訳ないです。
529：通りすがり：2020/02/08(土) 04:55:03 ID:64OamMms0: 申し訳ございません、RSSの方の掲示板へ書き込みしてしまってるようでして削除お願いします。
影響するのかはわかりませんが、Ver19等の対応も更新していたということで
www.7-zip.org
7-Zip 20.00 alpha
更新されました。

7-Zipは、LZMA / LZMA2圧縮用の新しいオプションがサポート→bt5およびhc5、
bt4およびhc4マッチファインダーよりも冗長性の高いデータに対してより速く動作します。
最速レベル（-mx1）：256 KBの辞書を持つhc5マッチファインダー。
高速レベル（-mx3）：4 MBの辞書を持つhc5マッチファインダー。
Normal / Maximum / UltraのマルチスレッドLZMA / LZMA2圧縮のマイナーな速度の最適化
圧縮レベル。
bzip2デコードコードは、lbzip2プログラムによって作成されたbzip2アーカイブをサポートするように更新されました。
いくつかのバグが修正されました。

私は超圧縮で使い続けております。
まだアルファのINSTALLしてませんので
-t7z -mx=9 -ms=off -m0=lzma2 -ssw
多重ファイルをキューに入れて行う時[.BATにて]のテストも見直しもしてないですけど。
530：x@rgs★：2020/02/17(月) 19:00:16 ID:???0: >>527

大変お待たせいたしました。
修正版を公開いたしましたので、ご確認のほどよろしくお願いいたします。
(7-zip32.dllのページの「人柱版」からダウンロードください。)
追加したSevenZipExtractMemEx()はバッファサイズをLONGLONGで指定できます。

>>529

ご報告ありがとうございます。
本家のソースコードが公開されましたら対応いたします。
531：kiyohiro：2020/02/19(水) 12:32:08 ID:I/v61Ywo0: >>530
どうもお世話になってます
掲示板の書き込みを拝見しました
修正箇所は試せそうにないですが
取り敢えずWinXpで動くかどうかだけでも試そうかと思い
ダウンロードしたいのですが見つからないです

> (7-zip32.dllのページの「人柱版」からダウンロードください。)
Home > ソフトウェア > 7-zip32.dll/7-zip64.dll/7z.dll文字化け対策版
のページでは無いのですか？
一応上から下まで見て人柱版をページ内検索とかしても何処なのかわかりませんでした
よろしくお願いします
532：通りすがりの人：2020/02/19(水) 19:36:55 ID:fqH/1Q3.0: 【OS】[Windows8.1 64bit]
【ソフト名】[Ashley]
【バージョン】[Ver.1.39]
【要望】１　リネームした際、同名ファイルがあれば自動的に末尾に (2) や (3) を付加してリネーム
　　　　２　リストからリネーム出来たファイルを削除し、エラーファイルだけを残したい
　　　　３　高度な設定のフォーマットの一覧に自分で作成した定型を追加したい

　リネームツールを探して、このツールにたどり着きました。
　非常に使いやすく、日頃から愛用させて頂いております。
　普段使っている中で、この機能があればより使いやすくなると感じた点をあげてみました。
　ご検討頂けたら幸いです。
533：x@rgs★：2020/02/19(水) 22:09:04 ID:???0: >>531

ご指摘ありがとうございます。
正しくアップロードできていなかったため修正しました。
ご確認ください。

>>532
投稿ありがとうございます。
要望について、1はオプションで実装できるかと思います。
2は「リネームに成功したファイルを全てリストから削除」を実装でよろしいですか。
リネーム成功ファイルを選択or失敗ファイルを選択でも、「選択範囲を反転」や「リストから削除」を組み合わせて実現可能ですが…
3はちょっと難しいかもしれません。例えば、%extで拡張子を表すようにして欲しい…とうことであれば追加します。
新しいファイル名のフォーマットをいくつか保存し、リストから選択したい…とうことであればそのような機能を検討します。
534：通りすがりの人：2020/02/19(水) 23:09:31 ID:fqH/1Q3.0: >>533
ありがとうございます。

２に関しては、リネームする際、成功したファイルより失敗したファイルを再リネームすることの方が多いため要望を出させて頂きました。
現行の機能で対応可能であれば、私の認識不足でした。申し訳ありません。
ただ、「リネームに成功したファイルを全てリストから削除」を実装して頂けるなら大変助かります。
３については、現在、元々のアーカイブ内に含まれない固定文字を付加してリネームするのに、
高度な設定のフォーマット入力フォームに固定文字を追加入力してリネームしているのですが、
毎回固定文字を付加する訳ではないので、そのたびに入力し直しており、それらを保存してリストから選択できたらと思った次第です

技術的に困難、手間がかかるのであれば無理にとは申しませんが、実装して頂けるなら大変助かります。
実際のところ、エラーになる原因のほとんどが同名ファイル存在のため、１だけでも非常にありがたいです。
535：tenteko：2020/02/20(木) 00:27:21 ID:6h5qm12k0: ＞＞530

対応ありがとうございました！

SevenZipExtractMemEx()についてだけですが、早速試させて頂きましたところ、
4,294,967,295バイトを超える書き出しも大丈夫なようです。
（符号『有り』のLONGLONGで宜しいのですよね？）

加えまして、解凍時におけるメッセージ（ARCEXTRACT_BEGIN(0)とARCEXTRACT_INPROCESS(1)）も
共に送出されておりました。

ただ、ひとつ問題を発見しました。
説明致しますと、

①SevenZipExtractMemEx()を実行。

②解凍中、コールバック関数に return true させている間は、正常に処理を継続する。

③解凍中、コールバック関数に return false させると、処理は中断（ARCEXTRACT_END(2)）へ向かうが、
その後プロセスがフリーズし、SevenZipExtractMemEx()が戻り値を返さなくなる
（SevenZipExtractMemEx()より後へ処理が進まなくなる）。

重ね重ねお手数をおかけしますが、対応頂ければ幸いです。
536：x@rgs★：2020/02/23(日) 00:12:55 ID:???0: >>534

2…「リネームに成功したファイルを全てリストから削除」を実装します。
3…「独自文字列を追加」機能(;で区切ると複数指定可能)を実装します。
公開までしばらくお待ちください。

>>535
ご報告ありがとうございます。
修正しましたのでご確認ください。
なお、SevenZipExtractMemEx()の引数は符号ありLONGLONGです。
537：x@rgs★：2020/02/24(月) 11:42:19 ID:???0: >>534

お待たせいたしました。
人柱版を公開しましたのでご確認ください。
要望1:オプション「高度な設定」→「重複時自動リネーム」
要望2:編集メニューなど→「リネーム済みのファイルをすべてリストから削除」
要望3:オプション「高度な設定」→「新しいファイル名のフォーマット」→「フォーマットの追加」
のとおりです。

重複時自動リネームはチェックを付けて有効化してください。
デフォルトの設定「%new(#)」だとfile(1).zipのように一桁で1からスタートします。
設定で「%new(##)」のようにすると、file(01).zipのように0埋めします。

想定していた機能と違う等あればご指摘ください。
538：tenteko：2020/02/24(月) 15:21:31 ID:4Hi1m3GA0: 度々の対応、ありがとうございます。

7-zip64.dll（7z.dll対応版ではない方）だけですが、
試させて頂いた結果を報告させて頂きたい思います。

まず、メッセージについてですが、次のような状態でした。

●ARCEXTRACT_OPEN(3)で return false した場合
その後はメッセージが送出されず、プロセスがフリーズ。
SevenZipExtractMemEx()が戻り値を返さなくなる。

●ARCEXTRACT_BEGIN(0)で return false した場合
その後、ARCEXTRACT_INPROCESS(1)とARCEXTRACT_END(2)は送出されるが、
ARCEXTRACT_END(2)後はフリーズ。
SevenZipExtractMemEx()が戻り値を返さなくなる。

●ARCEXTRACT_INPROCESS(1)で return false した場合
その後、（ファイルサイズによってARCEXTRACT_INPROCESS(1)が何度か送出された後）ARCEXTRACT_END(2)は送出され、正常終了。
SevenZipExtractMemEx()が戻り値としてエラー（0以外の数）を返す。

●ARCEXTRACT_END(2)で return false した場合
正常終了する。
SevenZipExtractMemEx()が戻り値としてエラー（0以外の数）を返す。

…ARCEXTRACT_OPEN(3)とARCEXTRACT_BEGIN(0)のときに問題があるようです。

次に、SevenZipExtractMemEx()のメモリへの書き出し自体についてですが、
データが壊れた状態で書き出されます。
ただ、戻り値は返されているようです。

また、アーカイブの解凍時、アプリケーションが落ちることがあります。
具体的には次のような状態でした。

●特定のアーカイブを解凍すると、必ず落ちる。
ただし、ARCEXTRACT_END(2)まではメッセージが送出されていると思われる。

なお、前バージョンではメモリ書き出しについて問題は有りませんでした。

度々スミマセン…。
539：通りすがりの人：2020/02/25(火) 21:21:15 ID:iQOFrb6o0: >>537
対応ありがとうございます。
自動リネームも編集可能と想定以上の追加機能で大変助かりました。
これからも応援しております。
頑張って下さい。
540：通りすがりの人：2020/02/25(火) 22:36:08 ID:iQOFrb6o0: >>539
ひとつ書き忘れていました

人柱版では起動時とリネーム時にたまにセキュリティソフト（ウイルスバスター）が反応してソフトが落ちることがあります
起動時はセキュリティソフトの除外設定に登録しておけば回避可能でした
リネーム時はおそらく私がリネーム規則をいじっている時に発生しているものと思われますがまだ条件がわかりません
わかりましたらご報告致します

他の方で発生するかどうかは不明ですし、おそらく私の環境と使い方のせいだと思われますので参考までに
541：x@rgs★：2020/02/27(木) 04:19:12 ID:???0: >>538

お待たせいたしました。
中断時のフリーズと正しくメモリに出力されない不具合を修正しましたので、
ご確認ください。

>●特定のアーカイブを解凍すると、必ず落ちる。
>ただし、ARCEXTRACT_END(2)まではメッセージが送出されていると思われる。
この不具合は当方の環境では確認できていません…。
もし今回のバージョンでも発生するようでしたら、
当該ファイルを送っていただくことは可能でしょうか？
よろしくお願いいたします。

>>539-540

ご報告ありがとうございます。
セキュリティソフト関連は少し気になります。
もし条件等が分かりましたらご連絡いただけると幸いです。
542：tenteko：2020/02/29(土) 21:54:49 ID:4Hi1m3GA0: 毎回対応いただきまして、本当にありがとうございます。

今回も7-zip64.dll（7z.dll対応版ではない方）だけですが、報告させていただきます。

●SevenZipExtractMem()実行時、コールバック関数で受信した各メッセージに対し return false した場合、
件の４つのメッセージの何れのケースでも正しく終了し、戻り値としてエラー（0以外の数）を返す。

●書き出したデータも壊れることなく正常に書き出されている（ように思います）。

●前回報告した「特定のアーカイブを解凍すると、必ず落ちる」という現象については、
該当するアーカイブを削除してしまったので試せる状態ではないのですが、
色々と解凍を繰り返しても同様の現象には遭遇しないため、
恐らくデータの書き出しが修正された時点でこの問題も修正されたのかもしれません。
（もし同様の問題に遭遇したときには、また報告させていただきます）

というわけで、報告させて頂いておりました不具合は無くなったようです！

…ただ、２つほど、別の問題を見つけてしまいました。

１つ目は大した問題ではないのかもしれませんが、次の様な現象が発生します。

●フォルダを含むアーカイブをSevenZipExtractMem()で解凍した場合、
実行ファイルがある場所にそのフォルダ（空）が生成されてしまう。

２つ目は、これはこちらで聞くべきことなのかどうか分からないのですが、
もし宜しければご教示頂ければと思います。

現在、OpenSiv3DというC++フレームワーク？で 7-zip64.dll を利用しているのですが、
VS C++ 2019 にて、ウィンドウ上部の再生ボタン？（ローカルWindowsデバッガーと書いてあるところです）を押して、
ここからDebugビルドとReleaseビルドが実行されている分には、SevenZipExtractMem()は十分に機能してくれているのですが、
VSを通さず、直接実行ファイルを実行すると、SevenZipExtractMem()が実行された時点で
アプリケーションがフリーズ（というか、SevenZipExtractMem()を実行したメインスレッドだけが止まっているっぽい？）します。
（このとき、上述の空フォルダが作られる現象は発生します）
前に「SevenZipExtractMem()を実行後に戻り値が返ってこず、プロセスが止まる」というのが有りましたが、
それとよく似ている…のかもしれません。

以上のように、VSを通したときと通さないときとでプログラムの挙動が違うわけなのですが、
何か対処方法等、思い当たるものがあるようでしたら、ご教示願えませんでしょうか。

因みに、SevenZip()など、その他のDLLの関数ではフリーズしないようです。

何分、DLLを用いたプログラムは今回が初めてでありまして、
もしかしたら勝手がわからずに何か根本的な間違いを犯しているのかもしれません…。

■追伸
OpenSiv3Dを利用するのではなく、VSのコンソールアプリのテンプレートからSevenZipExtractMem()を実行すると、
フリーズは発生しませんでした（が、空フォルダが作られるのは同じです）。
543：x@rgs★：2020/03/06(金) 18:23:25 ID:???0: >>542

お待たせいたしました。
報告いただいた不具合を修正しましたので、
ご確認ください。

実行方法によってフリーズしてしまう不具合について、
OpenSiv3Dは書き方が分からなかったため、OpenSiv3D環境下ではテストできていません…。
同様の不具合が発生するAutoHotkey下で動作を確認しましたので、おそらくは動作するものと思います。

OpenSiv3D環境下でのご報告をいただけるとありがたいです。
よろしくお願いします。
544：tenteko：2020/03/08(日) 02:08:31 ID:4Hi1m3GA0: ＞OpenSiv3D環境下でのご報告をいただけるとありがたいです

OpenSiv3Dの実行ファイル単独で実行しても、フリーズすること無く動くようになりました！
このままだとプログラムが完成しても単独で実行できないのでは意味がない…とヒヤヒヤしておりましたので、
これで安心してまたプログラムが組めます！
本当に有難うございました。

因みに原因は何だったのでしょうか？
後学までに教えて頂ければ嬉しいです。

あと、空フォルダの生成も無くなっていたのを確認いたしました。
こちらもありがとうございました。

…ところで、また２つほど問題を見つけてしまいました。

①

今現在、SevenZipFindFirst及びSevenZipFindNextを実行し、最初に見つけた画像ファイル（拡張子で判断）だけを解凍し、
ここからサムネイル画像を作る、ということをやっております。
それで、例えばSevenZipExtractMemExの第２引数に渡すコマンドラインを次のようなものにしているのですが…。

"x \"D:/test/test.zip\" -ir!\"test\\001.jpg\" -hide"

通常の場合はこれで解凍できているのですが、
アーカイブ内のファイル名（或いはフォルダ名）の中で半角スペースが２つ以上続く（以下、NGワード）とフリーズしてしまうようです。
（アーカイブファイル名の方では当該NGワードの有無は問題にならないようです）

なお、上記のように特定のファイルだけを解凍するのではなく、全てを解凍するような場合は、
NGワードの有無は関係なしに解凍できているように思います。

②

公式の7-zip（ver.19.00 x64）でLZMA2で圧縮したアーカイブをSevenZipExtractMemExで解凍したところ、
解凍自体は正常に行われているようなのですが、
LZMA圧縮アーカイブを解凍したときは、アーカイブ内の各ファイル毎にARCEXTRACT_BEGINが送出されるところ、
LZMA2圧縮アーカイブを解凍したときは、必ずしも各ファイル毎にARCEXTRACT_BEGINが送出されるわけではない、
という現象が発生しているように思います（アーカイブによって状況が異なる？）。

ARCEXTRACT_BEGINとARCEXTRACT_ENDを各ファイル書き出し完了のフラグを立てるのに利用していることもあり、
ちょっと困っております。
もしかしたら7zip自体の仕様なのかもしれませんが、修正は可能でしょうか。
545：x@rgs★：2020/03/08(日) 14:28:04 ID:???0: >>544

ご報告ありがとうございます。
無事動作したようで何よりです。

標準出力の割り当てに失敗していたことが原因です。
これを回避するために、裏でcmd.exeを立ち上げたりしています。

新規不具合について、
①これは「-i」スイッチ自体を二重引用符で囲うようにすると正常に動作すると思います。
-ir!\"test\\00 1.jpg\"
↓
\"-ir!test\\00 1.jpg\"
ファイル名部分だけを囲うと、7-zip32.dllの内部で
\"-ir!\"test\\00\" \"1.jpg\"\"
と解析されてしまうようです。

②いくつかLZMA2なアーカイブを作成しテストしましたが、当方の環境では再現できませんでした。
差し支えなければ当該ファイルを送付していただくか、構造等を教えていただけると幸いです。

その他、毎度々々のフリーズの原因であるパイプ読み込みスレッドの処理を改善したバージョンを公開しました。
546：x@rgs★：2020/03/08(日) 14:55:34 ID:???0: >>545

追記です。
不具合①は本家7-zip32.dllでも報告されており、
今後ファイル名を囲う方法も対応していく予定のようです。
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

ご報告ありがとうございます。
手元の環境では再現できなかったため、あやしいところを修正しました。
ご確認ください。