Skip Invalid Patch

[NewsArchive]

Hey,

the Function:

Install File(s) => Patch =>

> Skip Invalid Patch
>
>
> [in] If this checkbox is marked, the file will be skipped during the file installation process if the file to be updated is not a valid update candidate.
>


Can you tell what is not a valid candidate update ?
What is considered in order to apply it?

Best Regards

db

[NewsArchive]

> [in] If this checkbox is marked, the file will be skipped
> during the file installation process if the file to be
> updated is not a valid update candidate.
>
> Can you tell what is not a valid candidate update ?
> What is considered in order to apply it?

It's exactly what the message says. The file will be skipped during the
file installation process if the file to be updated is not a valid update
candidate. A patch file is an update or revision file that contains only
the differences between two or more files. If the previous file version on
the target machine is detected as "invalid" (means you forgot to build a
binary patch for it) then the installation skips that file (if the option is
enabled).

For example, you build a patch for file revision 1.01 and 1.03. On the
target machine, the installer detects build 1.02 and it will not (and can't)
apply the patch (because you did not generate the binary difference).

Hope this helps.

BTW, you need a rock-solid deployment strategy to successfully use delta
differences. Only use it if it really makes sense. It adds an extra layer
of complexity to your project!

Friedrich

[NewsArchive]

Thanks for the info's.

Unfortunately, it helps me not with my problem further :(

db

[NewsArchive]

> Thanks for the info's.
>
> Unfortunately, it helps me not with my problem further :(

What is your problem :)

Friedrich

[NewsArchive]

Deployment is cool.<g>

>
>BTW, you need a rock-solid deployment strategy to successfully use delta
>differences. Only use it if it really makes sense. It adds an extra layer
>of complexity to your project!

Jeff Slarve
www.jssoftware.com
www.twitter.com/jslarve
This post may self-destruct at any moment

[NewsArchive]

>
> Deployment is cool.<g>
>

Yep <g>

Friedrich

[NewsArchive]

You can fit a lot of binary patches on a 1.2MB floppy....

Jane Fleming

[NewsArchive]

Hi Jane,

.... maybe on a 5" but not on an 8".

In South Africa we had 8" floppies, followed by 5" floppies, followed by
3" 'stiffies'.
NOW we really mean business. A standard stiffy was 720KB and HD was 1.44MB!
Then there was "talk" of a forthcoming 2.8MB stiffy too which didn't really
catch on.
For some strange reason, 'stiffies' continued to be called 'floppies' in
the UK and the US.

Sim

[NewsArchive]

One is all I need<g>

Jeff Slarve
www.jssoftware.com
www.twitter.com/jslarve
This post may self-destruct at any moment

[NewsArchive]

OK

I try to explain our problem ;)

We have a very special software to be created actually always individual.

This works fine with the compiler variables in the configuration!

Now it's about the updates.

If user A the file xyz.cfs or xyz.exe in abc directory has, it does not
mean the user B has the same files appear if the same file name.

Example:

User A:

directory abc =>
xyz.cfs => Date 21.03.2012
xyz.exe => Version 8.05

User B:

directory abc =>
xyz.cfs => Date 24.03.2012
xyz.exe => Version 8.04

If I create an update to user A, and wants to replace the files above, I
must specify the previous file version, so that the files are updated.
But the files from the user B can not be replaced.

My problem is the previous versions.

1. We always replace the entire file - no binary patch
2. The file may only be replaced if any of the previous file is found.
And I must have the ability to say the date is important - or the
checksum or the file version.

The management of the previous version, is too complicated for me.

I must always select the files and I must always have the files on the
computer at any future patch.

But if I do not need binary patch and store the information of the
previous files in an XML file would, I could delete the old versions or
overwrite for the next patch.

We create for our customers individual patches sometimes 2-3 per week.

Since then an administration makes an XML file, the whole thing easier,
I think.

db

[NewsArchive]

Hello,

As I understand it, you do not need the "binary patch" feature at all for
your project. If the expected "bandwidth saving" is not at least 1TB then I
would avoid the extra layer of complexity imposed by delta updates.

Similar to the following. One of our customers releases 12 updates per year
to 45,000 customers. The full update install size was 178MB, the binary
patch file size is only 12MB.

Some impressive figures:

45,000 x 178MB = 7,822GB x 12 = ~93,864GB
45,000 x 12MB = 527GB x 12 = ~ 6,324GB

The company has to pay $0.110 per GB (data transfer pricing). That means,
before using binary patching they had to pay $10,325 per year for update
data transfer. But with binary patching (delta update), they pay only $695
per year and SAVE $9,630!!!!

Friedrich

--
Friedrich Linder
Lindersoft
www.lindersoft.com
+1.954.252.3910

SetupBuilder is Windows installation -- "point. click. ship"

-- Official Comodo Code Signing and SSL Certificate Partner

[NewsArchive]

I think it's so nice to me that you are recreating a calculation, but

First it does not solve my problem
Second we have no limitation in terms of our traffic :)

db

[NewsArchive]

> I think it's so nice to me that you are recreating a calculation, but
>
> First it does not solve my problem

I think your problem is "only" a deployment strategy problem.
Unfortunately, it's not related to SetupBuilder itself and out of the scope
of technical support, so I fear I can't help with that.

You mentioned the "Skip Invalid Patch" function which is a "binary patch"
option. That's why I posted the real-life delta patch scenario. But (as
far as I can see) you are not using binary patch at all. And as I
understand it, your project is not even a cadidate for the binary patch
strategy (because your bandwidth is not limited).

BTW, you can use the "Get File Info..." script function to retrieve
information about existing files. So you can check for "valid" previous
versions (based on CRC-32, version, date/time, etc.) and then act
accordingly.

> Second we have no limitation in terms of our traffic :)

Cool :)

Friedrich

[NewsArchive]

I still have a stiffie in my drawer <vbg>

J André Labuschagné