Patch Install Decompression Error

[PaulS]

I was getting this error yesterday, so this morning I built a new install from scratch. First I created a setup that installs a set of binary data files that will be used by an application. This install seems to work fine and the files compare good to the original source files.

I then saved the sb7 project under a new name. In this project, for each file being installed, I modified the file datails on the "Patch" tab to point it at a previous version of that file. The install compiled fine that I can see. However, when I run this install it updates one file just fine, but reports the decompression error when its processing the second file.

I've attached a ZIP file with the SB7 project file (and other information that might be useful).

I'm currently using a really old version of WISE that handles these same binary files just fine, but I need an installer that supports 64-bit Windows systems.

The above was all done on Win XP Pro SP3 running in MS Virtual PC 2007 using an evaulation version of SB Developer (v7.2.3062). VPC host system is Win XP Pro SP3 on Intel Core2 Quad CPU (Q6600).

[linder]

Hello Paul,

I think your protection software product is overprotective and "locks" the file process. What happens if you disable your anti-virus system? What kind of anti-virus and anti-spyware system do you have?

BTW, I would suggest to put "Start Delayed File Install" and "Stop Delayed File Install" around your install files actions!

If it still happens, would it be possible for you to send the "old" and "new" files to support [at] lindersoft [dot] com so we can create a test patch here?

Friedrich

[linder]

BTW, we have used your DbUpd_Test3.sb7 project with "fake" files here. That means, we have replaced your "old" and "new" files with test binaries and the patch worked without any problem on XP Pro SP3, Vista Ultimate (32-bit and 64-bit), Windows 7 Ultimate (32-bit and 64-bit) and Windows Server 2008 R2 (64-bit).

So I assume "something" locks this process on your machine. If you are interested, you can send us your old/new files and we'll compile and test it here on our machines.

Friedrich

[PaulS]

I'm sending an email, subject same as this thread title, with the old and new version of the file that the error occurs on.

The Win XP Pro SP3 VM I'm doing this development/testing in doesn't have a virus scanner or other such installed. I'm using a VM to keep from polluting my main dev system (which is hosting the VM) and to keep stuff on my main dev system from polluting this development work that I'm doing in the VM.

At the present I've only been using SetupBuilder in this VM to evaluate install tools, so nothing should be using the files I'm trying to patch. The folder I'm installing to is completely separate from the source folders the SB7 project is using.

I added "Start Delayed File Install" and "Stop Delayed File Install" around the install files. I don't get the decompression error now, but instead the install reports "the wizard was interrupted before xxx could be completely installed."

The sbevents.txt file still shows the following error.

|09/10/2010|11:30:56:931|Install file: C:\MediSpan\Db\data\tsclsing.hsh
|09/10/2010|11:31:00:436|Err02: 1 - File: C:\MediSpan\Db\data\tsdbase.dat
|09/10/2010|11:31:00:436|RunScriptEnd

Thanks for your help on this.
---Paul

[linder]

Paul,

We also tested your script on VMWare virtual machines and it worked as expected (but of course, with "fake" binaries). So perhaps your original files make a difference.

BTW, I checked this with our support, but we have not received the files yet. We'll keep looking for the email.

Friedrich

[linder]

Paul,

Files received. We'll test it on some machines and I'll get back to you.

Friedrich

[linder]

Paul,

We can reproduce this with your original files. The resulting binary patch streams is invalid and causes this issue. Please use the "Alternative Patching Method (LSPatch)" (see attached screenshot) for this file. Does this work?

Friedrich

[PaulS]

Using "Alternative Patching Method (LSPatch)" for this data file seems to have corrected the problem. Though it would be nice if the compiler had a option to turn on detection for these kind of problems.

After testing the install I notice that the files that didn't actually change still have their original date/time. Is there an option available to touch the files that didn't change forward to the "new" file date/time?

Looking at the "Build Report" that was created for this patch install I see that the reported size of the file patch is much larger than the original "New" file for some files. Here's an example.


00007 tspidmid.hsh %_SB_INSTALLDIR%\data
C:\MidWare\UsaEng\M\Db\data Always Install 2010/07/30 13:37:18 24,964 386A0917

00007 tspidmid.hsh[Patch] %_SB_INSTALLDIR%\data
C:\MidWare\UsaEng\M\DbLast\drug Always Install 2010/07/02 13:10:04 1,000,006 7CD64EDD

Which one is the compiler putting into the install file?
In this instance it would be more space efficient to just store the new file instead of the patch data.

Side note: The path reported for the previous (old) file is wrong for this file(see red above).

---Paul

[linder]

Paul,

Unfortunately, it's not possible to detect this at compile time. Windows generates an "uncompressable" binary patch data stream in your case (the same data stream also fails when zipped/unzipped with WinZip). BTW, I have seen this only three times in seven years (and SetupBuilder powers quite a few million installs and updates).

There is no built-in function to set the date/time stamp of files. If a patch is not applied, then the file is not touched at all.

The compiler always includes the file that has the [Patch] item. Could you please send the .htm and the tspidmid.hsh (old and new) files to our Support so we can check if the compiler report is incorrect (and to check what causes the "drug" item).

Thanks,
Friedrich

[linder]

It seems to be a compiler report problem. Your patch for tspidmid.hsh is only 726 bytes (see attached screenshot). Item in review. Unfortunately, we can't reproduce it so we'll check the source code.

Thanks,
Friedrich