File refuses to patch

[AdrianS]

I've run into a problem with a patch that doesn't yet make sense to me and I wonder if anybody else has seen it.

Here's the scenario:
The patch handles three versions of our software and affects 12 files. Of the 12, 11 are different in all three versions. One of the files changed from the first version to the second, but not from the second to the third.

The patch runs successfully when patching from version 1 to version 3, but it fails on the unchanged file when patching from 2 to 3, claiming that the target file doesn't exist. The failure is detected by a g_OnFileProcessed call with a ResultCode of 4.

The 2 to 3 patch starts alright, so it does identify the version correctly. The MD5 hashs for the source files and the target file all match. The build log for the patch showes two diff files for the 11 that change in both and one diff file for the file that only changes in 1 to 2.

Before I spent too much time digging into this, does anybody have any ideas what could be causing VP to think the one file doesn't exist when it does?

[AdrianS]

As a further test, I modified my g_OnFileProcessed function to display the MD5 of the offending file when the failure occurs. The displayed MD5 matches the source MD5.

[AdrianS]

I think that I now see where the problem is. While the ResultCode of 4 is defined as "The file was skipped because a matching target file could not be found on the system.", it seems that it also means that the file was skipped because there were no differences.

What got me confused was the fact that same file has been in our patches over about 15 versions without causing a problem. However, the file had never changed so it wasn't actually included in the patch. Now that it's in the patch, VP reports that it's been skipped.

This leads to a different question: How does one detect that the file patch really has failed?

We introduced this check into our patches because some of our users were modifying our DLLs to localize them. The patch would ignore those changed files, but would apparently succeed overall. The result was that some of the DLLs were at one version and others at another version. You can guess what kind of tech support issues that created.

[Lorne]

I think that I now see where the problem is. While the ResultCode of 4 is defined as "The file was skipped because a matching target file could not be found on the system.", it seems that it also means that the file was skipped because there were no differences.

Thanks, I've logged this for investigation. REF: 14170

How does one detect that the file patch really has failed?

If you mean from another program, you could check the process return code from the patch.

If you mean from within the patch...I'm not sure. I've logged that for investigation as well. REF: 14171

We introduced this check into our patches because some of our users were modifying our DLLs to localize them. The patch would ignore those changed files, but would apparently succeed overall. The result was that some of the DLLs were at one version and others at another version. You can guess what kind of tech support issues that created.

Yeah, no kidding. Did you try turning on "Force install" for those DLLs? (Maybe with a script condition that checks the version of the DLL to see if it's current...)

[AdrianS]

If you mean from within the patch...I'm not sure. I've logged that for investigation as well. REF: 14171

Yes, that's what I meant.

At this point the problem file is a 3rd party DLL that rarely changes. Currently all of the other files in the patch change between versions because they are all version tagged. It may only be one byte that changes, but they all change. Since only the one, rarely changing file is causing problems I dealt with it by specifically testing for its name and checking its MD5 in the g_OnFileProcessed function.