MultiArc - archiver plugin

Discuss and announce Total Commander plugins, addons and other useful tools here, both their usage and their development.

Moderators: sheep, Hacker, Stefan2, white

Post Reply
Hurdet
Senior Member
Senior Member
Posts: 474
Joined: 2003-05-10, 18:02 UTC

Post by *Hurdet »

Hurdet wrote:After that I use the computer with plenty of memory, if I use MultiArc to compress the file, the temporary file (in %TEMP%\$mltwcx) with the list of files to be compressed is not created and MA returns a "Errorlevel returned: 255".
So, if I restart TC fixes the problem.
Is a problem of MA or TC. you can solve it?
I've reproduced the problem:
I have a ramdisk in f:
i have %temp%=f:\temp
i use multiarc to pack and work, it create file list in f:\TEMP\$mltwcx\lst370.tmp
i unmount ramdisk
i remount ramdisk
i use multiarc to pack and not work, it not create file list in f:\TEMP\$mltwcx
also in the command line file list name is missing.
Restart Total Commander and MultiArc turn to work.
Do it is possible to fix it?

Hurdet
Senior Member
Senior Member
Posts: 474
Joined: 2003-05-10, 18:02 UTC

Post by *Hurdet »

Do it is possible to use MA for pack 7z archive and internal TC to unpack?

Why this:
Format0="yyyy tt dd hh mm ss a+ zzzzzzzzzzzz pppppppppppp n+"
work and this:
Format0="yyyy tt dd hh mm ss a+ z+ p+ n+"
not?

User avatar
Horst.Epp
Power Member
Power Member
Posts: 3705
Joined: 2003-02-06, 17:36 UTC
Location: Germany

Post by *Horst.Epp »

Hurdet wrote:Do it is possible to use MA for pack 7z archive and internal TC to unpack?

Why this:
Format0="yyyy tt dd hh mm ss a+ zzzzzzzzzzzz pppppppppppp n+"
work and this:
Format0="yyyy tt dd hh mm ss a+ z+ p+ n+"
not?
There is no need for MA to pack in 7zip format.
There are 2 plugins which are much simpler to handle
and no need to fiddle aroung in MA.
I prefer Total7zip which allows to use always the newest 7zip betas
with support for much more than 7zip.

User avatar
MVV
Power Member
Power Member
Posts: 8485
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV »

With TC 8.50 Multiarc started to fail unpacking due to incorrect working directory setting for unpackers. I've replaced all calls to SetCurrentDirectory with direct passing working directory to CreateProcess function to fix this problem.
If you have similar problems (e.g. you get error message when you're trying to view files inside InnoSetup archives by F3), you can try fixed version:

MVV Build #5 32+64

User avatar
deus-ex
Power Member
Power Member
Posts: 746
Joined: 2003-02-10, 17:45 UTC

Post by *deus-ex »

Hi MVV,

nice one, thank you for sharing with us. :D
Best regards
deus-ex

TW
Senior Member
Senior Member
Posts: 344
Joined: 2005-01-19, 13:35 UTC

Post by *TW »

thanks much MVV!
licenced and happy TC user since 1994 (#11xx)

User avatar
deus-ex
Power Member
Power Member
Posts: 746
Joined: 2003-02-10, 17:45 UTC

Post by *deus-ex »

Hi MVV,

I'm afraid I just discovered a bug with your latest release. I'm using the 64-bit binaries. Extracting any file stored in a subfolder from the archive UnRARDLL.exe will crash TC, though the files do get extracted. The files located in the root folder of this archive extract without any crash. Switching back to an older release of your MultiArc.wcx64 binary solves the issue.

Could you please look into this issue, and maybe make the previous version (build #4) available for download meanwhile? Feel free to contact me in order to identify and solve the above described bug.
Best regards
deus-ex

User avatar
MVV
Power Member
Power Member
Posts: 8485
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV »

deus-ex,
Thank you for the report. It is strange that #5 crashes while #4 does not, there were no other changes except passing working directory LPSTR to CreateProcess instead of SetCurrentDirectory.

As I see, your archive is RAR 3.0 one, and it is supported by TC directly. Please tell which unpacker do you use and post your unpacker addon. I'll try to reproduce this crash.

I've tried with InnoUnp and I don't get any crashes.

Also I tried it with your archive using UnRAR.exe 5.00 beta 6 and following addon and got no problems:

Code: Select all

[RAR5]
ID=52 61 72 21
IDPos=<SeekID>
SkipSfxHeader=1
Extension=wr5, rar5
Description=RAR 5.x
Archiver=UnRAR.exe
BatchUnpack=1
Debug=0
Start="----------- ---------  -------- -----  ----"
End="----------- ---------  -------- -----  ----"
Format0=" +aaaaaaa +z+ +dd-tt-yy hh:mm +n++"
List=%P l -- %AQA
Extract= %P e -y -scO {%S} -- %AQA @%LQ
ExtractWithPath=%P x -y -scO {%S} -- %AQA @%LQ
Test=%P t -y -scO {%S} -- %AQA
Delete=%P d -r -y -scO {%S} -- %AQA @%LQ
Add=%P a -y -ma -md128m -ed -oi:1048576 -s -t -scO {%S} %AQA @%LQ
Move=%P m -y -ma -md128m -ed -oi:1048576 -s -t -scO {%S} %AQA @%LQ
SkipLIST=1

User avatar
deus-ex
Power Member
Power Member
Posts: 746
Joined: 2003-02-10, 17:45 UTC

Post by *deus-ex »

Hi MVV,

I do not know whether #4 does not crash as I do not have it, to my knowledge you didn't make it available here. I had to revert to your initial release #1 as the download for #2 isn't available anymore.

The strange detail is that I actually do not have configured Multiarc to handle any RAR archive (not in wincmd.ini nor in MultiArc.ini) since TC offers the required functionality already. Still the crash described in my previous post is triggered with your release #5 installed. Replacing file MultiArc.wcx64 with the release from #1 does fix the issue for me. The file ConSpawn.pipe64 is the one from release #5 (which appears to be unchanged since #2).

Can you please make release #4 available for download or send it via PM (whatever you prefer) so I can check the bug against that release.

Thank you in advance.

P.S.: As explained I'm using TC internal routines to unpack along with the latest release of Unrar64.dll (v5.1.100.67).
Best regards
deus-ex

User avatar
MVV
Power Member
Power Member
Posts: 8485
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV »

deus-ex,
It is really strange that Multiarc causes crash when TC unpacks files using internal unpacker and doesn't call Multiarc... Anyway, I'm sure it is not #5 only issue (since you haven't tested some previous releases).

Conspawn project wasn't modified at all by me (maybe only before #1 in order to build it, executable wasn't changed since first release maybe except timestamps and checksums in header).

Here I've compiled all versions that I have (from backups), please try all in order to find out first buggy one (if you want to debug something I can send you sources).

Also please test some other things:
1. TC with clean configuration with only Multiarc registered.
2. Try to enter archive before loading Multiarc and after (TC doesn't load WCX plugins if it is able to open file itself so it will only load them on first unsupported file, e.g. you can do Ctrl+PgDn on any TXT and Multiarc will be loaded).

User avatar
deus-ex
Power Member
Power Member
Posts: 746
Joined: 2003-02-10, 17:45 UTC

Post by *deus-ex »

Hello MVV,

I have found it! The crash is indeed related to MultiArc. Here are the details:

First I tested all the MultiArc releases from #1 through #6 that you kindly provided. #1 to #4 work without issues, while using #5 or #6 does trigger the crash.

Then I ran TC with Multiarc being the only registered plugin, the crash still occurs with #5 and #6. So I checked my configuration in wincmd.ini and MultiArc.ini.

In the PackerPlugins section of wincmd.ini I have configured several extensions to point to Multiarc, among these I have the extension "exe" which I found to be related to the crash. Of course now I could see that due to the way I configured TC and MultiArc upon entering into EXE files via Ctrl-PgDown the MultiArc plugin is called, not TC & Unrar64.dll as I thought previously (sorry for that).

Next checking my MultiArc.ini and after some trials I found the following entry to be related to the crash:

Code: Select all

[ISO+RES]
Description="ISO + Resources"
Archiver=%commander_path%\Util\7-Zip\930\7z
Extension=exe, dll, iso, swf
Start="^-----"
Format0="yyyy tt dd hh mm ss aaaaa zzzzzzzzzzzz pppppppppppp  nnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnnn"
End="^---"
List=%P l %AAQ
BatchUnpack=1
ExtractWithPath=%P x -bd -scsdos -y %AAQ @%LQ
Hence something that you have changed from MultiArc release #4 to #5 is leading to the above described crash.

Also I just learned that starting with MultiArc release #4 the listing of UHARC archives is broken. Reverting back to release #2c or earlier (1a, 1b, 2a, 2b) does solve this issue. So unfortunately this is a similar case, something that you have changed from release #2c to #4 breaks support for UHARC archives (probably other archivers are affected, too?).

Thank you again for providing me with all the MultiArc releases of yours so I could test and narrow down the root cause, and even find another issue nobody reported so far. Hopefully you find a solution to fix it. Until then I stick with you release #2c which works excellent for me.
Best regards
deus-ex

User avatar
MVV
Power Member
Power Member
Posts: 8485
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV »

Thank you for detailed information, I'll test your addon with 7-Zip archiver. It would be great if you provide UHARC unpacker that you're using and some test archive (I've never had any UHARC archives).

User avatar
deus-ex
Power Member
Power Member
Posts: 746
Joined: 2003-02-10, 17:45 UTC

Post by *deus-ex »

Hi MVV,

UHArc v0.6b: download
I just send you an Email with a download link for an example UHARC archive.
Best regards
deus-ex

User avatar
MVV
Power Member
Power Member
Posts: 8485
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV »

Thank you, I'll try it.

I tested Multiarc with your 7z addon, unfortunately there are no bugs with debug version, or with release one with debug info enabled. However if I disable debug info, I get access violation and see that Multiarc calls some function from shell32.dll...

Strange, if I comment line with GetCurrentDirectory call, it crashes, however its returned value is not used more:

Code: Select all

bool CArchiverEngine::OnClose()
{
	bool bRet;

	if(m_pad->BatchUnpack() && m_pDeferedNames)
	{
		char szCurPath[ MAX_PATH ], * tmp, * workDir=0;
		GetCurrentDirectory(MAX_PATH,szCurPath);
And problem occurs somewhere inside of delete_files call:

Code: Select all

      if( bRet )
      {
        move_files( tmp, m_pStripPath, m_pDestPath );
        delete_files( tmp );
      }
Which calls SHFileOperation... It seems that error have been caused because not all fields of SHFILEOPSTRUCT structure have been filled (floating bug which become visible only after my changes).


deus-ex,
Please test next build, it shouldn't cause crash, also I fixed UHARC problem, please try it with all your packers.

MVV Build #7 32+64

And don't forget that since #4 you can replace 256 n's with just n++. :)

Hurdet wrote:Why this:
Format0="yyyy tt dd hh mm ss a+ zzzzzzzzzzzz pppppppppppp n+"
work and this:
Format0="yyyy tt dd hh mm ss a+ z+ p+ n+"
not?
I'll describe this. Second one doesn't work because "z+" stops at first space, but since 7z prints numbers right-aligned, for small numbers "z+" will stop immediately (there are a lot of spaces before number). However you can use " +z+" (note space before first +) and it will work because " +" will skip all spaces before number.
However I just noticed that 7z may simply omit (fills with spaces instead of printing any number) packed size value in case of solid compression so "z+" will skip all spaces until filename and it will cause parse error (because of shift packed size will be read from filename and filename will be empty). Finally I changed 7z format string to this one to bypass such cases:

Code: Select all

Format0="yyyy tt dd hh mm ss aaaaa zzzzzzzzzzzz pppppppppppp +n++"
However I don't know how 7z lists files larger than 1 TB. UnRAR simply makes that field longer when number of digits is insufficient, this produces shifts, and it was the main reason to introduce + sign: zzzzzzzzzzzz+ will read at least 12 digits (but it will read more until first space in case of huge numbers).

User avatar
deus-ex
Power Member
Power Member
Posts: 746
Joined: 2003-02-10, 17:45 UTC

Post by *deus-ex »

Hi MVV,

I tested #7 64-bit edition with the packers I regularly use (7-Zip, RAR and UHARC) and several SFX archives like the infamous UnRARDLL.exe. Everthing works as expected, I found no issues.

Well done! Thank you for your support and the quick update.
Have a nice Sunday. :D
Best regards
deus-ex

Post Reply