Synchronize tool and contents of TC installer

[ghisler(Author)]

There is no CAB packer, just a CAB unpacker.

[AntonyD]

There is no CAB packer, just a CAB unpacker.

Not a very significant correction but if you insist - I can rephrase my question using only the "unpacker" word.
But the essence of the question is still absolutely the same:

If there is NO any CAB unpacker- so HOW we can work with CAB archive content????
BUT if we CAN somehow to work with it - so obviously that any errors related to the process
of "unpacking" the any CAB archive should use only CAB name...
So WHY we still see the "ZIP"?

[ghisler(Author)]

1. Because I can't wait 2 months until I get replies from all translators, sorry.
and
2. Because it's actually the ZIP packer which tries to pack the files (fallback) because no other packer or plugin claimed to support it.

[AntonyD]

1)Why you can't simply to add support for CAB via internal mechanism? Even w/o additional translations?
2)Why for CAB archive your code even try to create an archive using resync. operation?
IF TC cannot write to it anyway - it KNOWS beforehand that it is the CAB archive!

[ghisler(Author)]

1) There is an API to create CAB files, but it cannot modify existing files, so it's not a simple process (would involve unpacking the entire old archive, replacing files, and adding new files). Nothing I can just add over night.
2) Because it's a fallback. When you change the name, you can still get a ZIP archive, but you are responsible for setting the right extension. I'm not restricting the extension the user chooses, e.g. so they can choose for example .docx, but this means that .cab isn't restricted either.

[browny]

Not sure if this would worth the trouble.
CAB archives have MSCF signature in the first four bytes.
In this case ZIP substring could be replaced with CAB in error messages; no translators involved.