[WCX] Handling of not associated archives

[Juergen]

Hi all,

as we know, TC handles archives that are associated with a packer plugin different than archives that have the same content, but just have a different file extension, which is not associated with the concerning plugin. For instance it is rather well known, that the latter can't be opened by pressing [Enter], but [Ctrl]-[PageDown] must be used instead.

Now I realized that there are some more differences.
For instance, when I'm trying to copy a file to an open archive that is associated with a plugin, and a file with the same name already exists inside the archive, TC asks me whether or not I want to overwrite the file inside the archive.
When I rename the extension of the archive, so that it's not associated with the concerning plugin any more, and I copy a file to the archive like before, now TC does not ask for confirmation any more! This behaviour is not expected, and can cause data loss!

• I want to suggest to change the mentioned behaviour in the next version of TC, in order to reduce the risk of data loss.

• There are more differences between handling of associated and not associated archives.
  Where can I find a complete documentation of all these differences?

Regards, Juergen

[ghisler(Author)]

Not confirmed! You probably tried to drag the file to the closed archive file instead of the open file (showing the archive contents). This will not work, because TC cannot recognize the file as an archive. The file will therefore be COPIED to the directory of the archive.

[Juergen]

Hmmm .... *scratching my head*
I actually was meaning copying a file to an open archive.

Say in TC's left panel I have opened an mbox file with my plugin (wich handles this as archive of e-mail files). Say the archive contains 5 files, and I can see a list of their names, sizes and dates (like a list of files in a directory). This is what I mean with "open".

In TC's right panel, I have just an empty directory. Now I copy one of the e-mail files from the archive to the empty directory. I change its contents a little, so that later I can distinguish it from the original file. The archive is still open in TCs left panel, since I see the list of files that it contains. So far, so good.

The point is what happens when I try to copy that file back to the open archive. When the archive has a file extension that is associated with the plugin, TC asks for confirmation, whether I want to overwrite the file in the archive, as I expected. BTW, in order to copy the file, I didn't use drag and drop, but cklicked at TC's [ F5 ] button (in case this is important).

When I do exactly the same, using the same archive just with another extension, which is not associated with the plugin, TC behaves differently! Now TC copies the file to the open archive, without asking for confirmation.

My plugin had reported CanYouHandleThisFile() = TRUE, TC has opened the archive, so it looks as if TC has recognized the file as an archive. And the file in the archive actually is overwritten with the new one. The struchture of the archive remains intact. Nothing is copied to the directory of the archive. In the directory where the archive is, there is no other file.

What plugin did you use for testing? What exactly did you test? Maybe this is a bug in my plugin, but on your website I coudn't find another packer plugin for comparison, which allows to add files to an existing archive.

Maybe I'm using a wrong method for packing? I do it this way:
I copy the files of the old archive that should be kept to a temporary archive, and addd the new files to it. If everything is OK, I delete the old archive, and the temporary archive gets its name.

I'm currently totally frustrated. :( What can I do?

Regards, Juergen

[Hacker]

Confirmed using the 7Zip plugin. XP SP2.

Roman

[Juergen]

Hello Roman,

thanks for the confirmation!

In the meantime, I have downloaded a bunch of packer plugins from totalcmd.net. Many do not allow adding files to an existing open archive, so they are not suited for testing this problem here. And only a few of them are able to add files to an existing open archive that is not associated with the concerning plugin.

Like you, I could confirm the problem with the 7Zip plugin (on Windows 98). Additionally, I could confirm it with the HA plugin.

I appreciate your independent testing. This was important, because previously I was not sure whether the problem was due to my plugin, whether I draw wrong conclusions or whatever. So thanks again.

Regards, Juergen

[Juergen]

In a few days, I'll release a new beta version of my mbox packer plugin. It will take care of the problem by displaying a dialog box itself, that asks the user for confirmation when appropriate. The plugin will contain some code like the following:

Code: Select all

if (ArchiveAssociated = FALSE) and (InterfaceVersion <= 2.10) then
   AskForOverwrite = TRUE
end if

Mr. Ghisler, when this issue will be fixed in the next TC version, can you then please increase the version number of the packer plugin interface? Otherwise, TC and my plugin will ask the user for confirmation in the cases described above, which of course is not intended.

Regards, Juergen

[Lefteous]

Confirmed

[Juergen]

Thanks, Lefteous.

Mr. Ghisler, I hope you'll also confirm this bug, and fix it in the next release of TC. In your last reply in this thread, you wrote that you couldn't confirm the bug, but without mentioning what you exactly did in order to do so. If my explanation was not too good understandable, then please tell us. I'm pretty sure Hacker and Lefteus will help, if I did not and will not find the proper (English) words to describe the problem.

Regards, Juergen

[Lefteous]

Maybe it's interesting to know that it works as expected for self-extracting ZIP files created by Total Commander.

[Juergen]

Confirmed.

Since these archives are not handled by a plugin but by TC itself, this finding IMHO supports the assumption that the bug is located in the packer plugin interface.

Regards, Juergen

[ghisler(Author)]

Mr. Ghisler, when this issue will be fixed in the next TC version, can you then please increase the version number of the packer plugin interface? Otherwise, TC and my plugin will ask the user for confirmation in the cases described above, which of course is not intended.

OK, I have taken a note. If I manage to reproduce the problem, I will make a new version of the interface, and report it to the calling plugin.

[vserd]

2 ghisler
if you planed revision WCX API, pleace fix bug with not calling CanYouHandleThisFile if extension registered in wincmd.ini
http://www.ghisler.ch/board/viewtopic.php?t=8463

[ghisler(Author)]

2vserd
This isn't a bug! CanYouHandleThisFile is only called for extensions OTHER than the registered extension, e.g. to open self-extracting EXE archives.

[Lefteous]

2ghisler(Author)

open self-extracting EXE archives

Will there be a way to open a file using different packer-plug-ins in TC 7.0?

For example SFX-EXEs:
1. Archive content
2. Ressources

In addtion it would be interesting to know how the order of packer plug-ins is determined which only work "by content" not by extension.

[vserd]

This isn't a bug! CanYouHandleThisFile is only called for extensions OTHER than the registered extension, e.g. to open self-extracting EXE archives.

Its bug (( or very not logically.

Because users register many same externsion (as EXE, CAB, 7z, Img, or other) in Wincmd.ini on different plugins. Its human logic. (If I needed in some task, I tel computer how to it is done).

Sample:
7z arhives. User can handle this archive in 2 special 7z plugins and Multiarc. And same time preffered plugin can not handle plugin, but it handled other plugin.

if I write registration as:

7z=223,%COMMANDER_PATH%\plugins\wcx\packer_plugins\MA\Multiarc.wcx
7z=495,%COMMANDER_PATH%\plugins\wcx\packer_plugins\7zip\7zip.wcx
7z=223,%COMMANDER_PATH%\plugins\wcx\packer_plugins\7z\7z.wcx

Its correct record in wincmd.ini, after reading help file.
I say TC: Try first plugin, if he cannot handle, try second, if secon cannon handle, try third, if third cannot handle, show error message (or do nothing).
Its logically, but not work , because TC not call CanYouHandleThisFile.
TC direct call first plugin, function return _Error_, and TC not call other plugins.
But plugin frankly say "TC! I Do Not Handle This File". But TC not ask this, and, as finish show error.

But if I write like this

7z_=223,%COMMANDER_PATH%\plugins\wcx\packer_plugins\MA\Multiarc.wcx
7z_=495,%COMMANDER_PATH%\plugins\wcx\packer_plugins\7zip\7zip.wcx
7z_=223,%COMMANDER_PATH%\plugins\wcx\packer_plugins\7z\7z.wcx

For iterate via plugins for handle arhive and this work, but not logically.
In this case TC serch direct match, not found, and from first registration record Enum plugs, and call CanYouHandleThisFile, plugin say "TC! I Do Not Handle This File" and TC
process other plugin.

On My opinion, registration in wincmd.ini many same extension and correct choice plugin reduse process time, and clean settings.

Many users ask how to use MultiArc plugin if InnoUnpaker plugin cannot handle arhive file, and users register plugin in Wincmd.ini on EXE extension.
For EXE externsion, if it self extracted Installation, I use Multiarc, Innounpaker, IETotal. If self extracted arhive Multiarc and other plugins, and I must write different, abstract, extension for register plugins.

Extension IMG it good sample of neded call, its picture, ISO Image, FDD image, HDD image, or special unknow for TC plugin format. And TC have more one plugin for handle this format.

P.S. maybe start topic for needed changes and bugs in plugin API? For fix, collect and realization in future versions.