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