Skipping File Compression

Is there a way to skip individual file compression? If not, consider this an enhancement request.

I am building a script that calls/runs an Installshield package. It's delivered by another organization who will not repackage in SB5 :rolleyes: nor will they release the files/script to me for conversion (Not like I would want to). It's already compressed by Installshield. Although (I think I want to) include the IS package in my SB5 package, I don't think it's necessary to compress this large file again. I'd just like to suck it in.

By the same token, how are native zip or (unix) compressed files handled?

Thx.

Hello,

At the moment the compiler automatically compresses all files into the setup.exe. Should save you again 3-4% (or more on InstallShield files). I'll see if it is possible to add a "skip file compression" function to a future build.

The included zip/unzip functionality supports the PKWARE 2.04g archive industry-standard. gzip is not supported.

Does this help?

Recompressing my 503Mb Installshield package in SB5 adds about 10mins to the package creation time. It's a productivity issue.

Uncompressing the file when the SB5 installation runs, takes many minutes, instead of about the 50 secs to merely copy the file. Again, it's a productivity issue.

On a priority scale of 1 to 10, I'd place it around a 5. Unfortunately, I think I need to include it in the SB5 package to insure integrity. I'm going to have to think about this some more, and consider alternatives like parking it in a separate directory and checksumming it or something to make sure I have the right Installshield file.

Thx.

I have submitted it to our suggestion database. Thank you!

We are encountering a situation where LSZip appears to be altering the contents of a file. This would be helpful for both prevention and further diagnosis!

Quote:

---

Originally Posted by linder

I have submitted it to our suggestion database. Thank you!

---

Are there any known issues with LSZip? We are encountering a case where the installed file does not match the build report (HTML file).

Hello,

what are you doing with LSZip from your setup.exe? Do you decompress a ZIP archive during the installation process?

But to answer the question, there are no known issues with LSZip. LSZip always checks the original CRC-32 value against the CRC-32 value after the decompression process.

Additional note: the SetupBuilder compiler and installer are using the LSPack (not LSZip). From the technical point-of-view, it is absolutely impossible that LSPack alters the contents of a file. During the compression process (when you build the setup.exe), it generates the CRC-32 value of the file and stores it in the archive header and in the script. After the decompression process, it generates again the CRC-32 value of the decompressed file and checks it against the stored CRC-32 value.

Friedrich

Hello,

LSZip will definitely never alter the contents of a file! It checks the CRC-32 before compression and the CRC-32 after decompression. Even if only one bit changes (e.g. file transmission error), you'll receive a decompression error.

BTW, the installer itself does not use LSZip. Only if you ZIP/UNZIP .zip files from within your installer then LSZip is used.

Friedrich

Hello Friedrich,

Thank you for your prompt response. I appreciate the clarification of LSPack versus LSZip. I have put together a sample project with the behavior that I am observing. Please note that the CRC in the build report is 72E37C6C, but the CRC of the installed file is 4C8BE551.

Regards

Hello,

very interesting issue (I can reproduce this with SetupBuilder V5 from August 2005, V6, V7, V8 and V10). I'll get back to you.

BTW, as a quick fix, change the "Fast" compression method back to "Standard".

Friedrich

Update: I think I know what causes this. We'll do some more tests. More later...

Friedrich

Hello,

we have a modified library for SB10. Can I send the new compiler component (only 10KB) to test it?

Friedrich

Yes, I will test it. What tests have you already run?

I'll send you a new small compiler component to test the fix. We have tested it on your .png file.

It's caused by this:

FIX : [SB#8-01151] Installer: Under certain circumstances, a possible silent buffer overrun resulted in an incorrect output if the compressed data size was between 65533 and 65535 bytes.

This issue is there since the first release of SetupBuilder 5 in 2005.

Friedrich

Hi Seth,

new compiler component sent.

Does this work?

Friedrich