Slow opening unsupported internally SFX archives

[MVV]

Hi to all. I like Total Commander very much. It's a most powerful file manager in the world. But I have one little trouble.

For example, I have an SFX 7-Zip archive (with size at least 500 MB, even on CD or DVD) and corresponding plugin installed.
I press Ctrl+PgDn... and wait... while TC checks that cannot open archive internally, while plugins tell the same thing... It may take even more then 30 seconds.

I guess TC scans whole file for the supported signatures. If so, I suggest to make an option to limit a piece of a file where signatures are looked. It will allow to speed up opening big archives. I think, even 1024 KB will be enough as default value there. Because most SFX headers have much smaller size, so it is inappropriate to scan whole file for the packer signature.

Also it will be great feature - an internal parametrized command to use defined packer plugin for opening file at the cursor.

[Lefteous]

Why do you think it's TC which accessed the file to find out if it's a supported (SFX) archive? TC just asks all installed packer plug-in which support this detect archive by content function until one says "hey I know how to handle it". It could be the 7zip plug-in but it could be some other which is slow at checking the file content. It could also be the sum of a lot of packer plug-ins.

[MVV]

I checked this with no external plugins installed. I pressed Ctrl+PgDn on SFX 7-Zip archive - and TC hung on significant time while trying to determine archive. While testing, I removed unrar.dll, unace.dll and wcmzip32.dll from TC folder. So, just TC remains. BTW, for example, if I pass to 7z.exe huge file, 7z.exe just immediately says if file is unsupported.

Once I tried to write some packer plugin for TC, so I know packer plugins structure and functions. But I understood that it is not a plugin trouble, so I can't fix it personally.

[sqa_wizard]

May this is related to the fact, that TC is scanning for a possibly solid archive (with internal rar functions) ...

[MVV]

I think TC just scans a file for any known archive signature. But sometimes it is too slowly to scan whole file for it. So it will be great to limit file position for such scanning.

[ghisler(Author)]

It may also be a virus scanner which knows the 7zip format. Some scanners scan the entire archive every time you try to access it, which can take a lot of time. Normally it's sufficient to set the scanner to scan only unpacked files, because when you unpack an EXE for running it, it will be scanned then anyway.

[MVV]

Yes, I thought about it. I closed my anti-virus scanner specially during last test.
I paid attention to this problem in 2005-2006, but I can't correct it personally. I have no more ideas. And you know your TC's code much better.
You can easy repeat this situation. Take an 7-Zip archive with size at least 500 MB, install 7-Zip or MultiArc packer plugin (if you have no it). Then, press Ctrl+PgDn and wait...

[icfu]

I can confirm that bug, TC is hanging while scanning the complete(!) file for the header, I checked with FileMon. It doesn't make a difference if a suitable plugin is installed or not, TC attacks with his internal routine first.

The scanning also occurs when Ctrl+Q is pressed on the file, with no lister plugins loaded of course...

Icfu

[ghisler(Author)]

Hmm, that makes little sense. Does the file contain anything which makes it look like some other archive like ZIP or RAR? TC will then look for the beginning of that data, but since it cannot find anything, scan the entire file for it...

[icfu]

Does the file contain anything which makes it look like some other archive like ZIP or RAR?

I have packed an arbitrary file, in this case a 700 MB video file, to a self-extracting 7z-Exe with 7-Zip 4.57. Neither WinRAR nor 7-ZIP have any problems to identify the file as a 7-ZIP SFX and the 7-Zip plugin opens it right after TC stops scanning it.

As Ctrl+Q hangs too, the archive comment functionality is involved as well I guess...

Icfu

[ghisler(Author)]

I have checked it in the debugger now. It's indeed the CAB unpacker which searches the entire file! I will limit its search range to the first 2 MBytes after the packer code section, that should be more than enough.

[icfu]

MultiArc uses 1 MB by default, afaik there have never been any problems with that range, so indeed 2 MB should be enough.

Icfu

[MVV]

Thanks to all. Let's wait for next version.