bug when patch includes a new file

[jlsf2]

I've added a new file to my patch that does not always get added when the patch is run.

Here's the scenario:
v1.0 - does NOT include the file driver.dll.
v1.1 - does include the file driver.dll - test release only
v1.2 - does include the file driver.dll

My patch only includes v1.0 and v1.2 since v1.1 was for internal testing only.

The problem is that v1.1 includes a different version of driver.dll than does v1.2.

When I run the patch to go from v1.0 to v1.2 AND if the test version of driver.dll already exists, then the patch will NOT overwrite the old driver.dll with the new version of driver.dll that is in the patch.

Is this correct? Seems like it should overwrite.

I could break driver.dll out (currently part of a folder add) and set the flag to overwrite always, but that seems like a hack (and requires that I know about every new file in my build).

Any ideas?

Thanks.

[Lorne]

Originally Posted by jlsf2

I've added a new file to my patch that does not always get added when the patch is run.

Here's the scenario:
v1.0 - does NOT include the file driver.dll.
v1.1 - does include the file driver.dll - test release only
v1.2 - does include the file driver.dll

My patch only includes v1.0 and v1.2 since v1.1 was for internal testing only.

The problem is that v1.1 includes a different version of driver.dll than does v1.2.

When I run the patch to go from v1.0 to v1.2 AND if the test version of driver.dll already exists, then the patch will NOT overwrite the old driver.dll with the new version of driver.dll that is in the patch.

Is this correct? Seems like it should overwrite.

Yes this is correct. By default Visual Patch will only update files that match the original source file. There are many reasons for this, but two very important ones are security and the nature of binary differencing.

1. Security - in a whole-file patch, updating a file that doesn't match the original source file in the identified version would provide an exploit to illegitimate users. (Just install a "fake" source file and get your patch to "update" it.) By only updating source files when their MD5 signatures match the original source files, Visual Patch guarantees that your patches can't be applied by someone who doesn't have a legitimate copy of the previous version.

2. Binary differencing - binary differencing uses the data inside the source file to build the new verison. This can only work if the source file matches the original file (that was used to build the patch) exactly.

I could break driver.dll out (currently part of a folder add) and set the flag to overwrite always, but that seems like a hack (and requires that I know about every new file in my build).

It also means that the entire file will be included in the patch (which might increase the size of the patch).

If you want your patch to be able to update version 1.1, you need to include version 1.1 when you build the patch. Then the patch will be able to update both versions (1.0 and 1.1).

If you didn't release version 1.1 to the public, then you don't need to include version 1.1 in the patch -- but you shouldn't expect the patch to still be able to update files from version 1.1.

[jlsf2]

That makes sense except in my case (I think).

The file on the user's system isn't supposed to be there so it isn't in the patch at all. The file is supposed to be new for the latest patch that I'm updating to.

So there is no matching to the original, since it isn't part of the original version that I've identified.