fault tolerance

[rjfioravanti]

Just wondering what happens in the following scenarios...

1. Computer shuts down while patching (power outage or something)

2. Patch fails to apply halfway through for some reason so a rollback initiates, then computer shuts down while rolling back

3. A binary file (not a key file) has been modified from the version's original state, and a patch is applied


Thanks

[Lorne]

Just wondering what happens in the following scenarios...

1. Computer shuts down while patching (power outage or something)

2. Patch fails to apply halfway through for some reason so a rollback initiates, then computer shuts down while rolling back

Tough question!

It's somewhat undefined, since it depends on what is happening at that very instant at the file system level. But in both cases you will likely end up with a frankenstein version -- with some files that are patched, and some files that are unpatched (either because they weren't patched yet or they were already restored).

Power loss may cause file corruption if a file is being written when the computer shuts down; if that happens during the patching process it could result in a corrupted file.

For both (1) and (2) it might be possible to correct everything by simply reapplying the patch, if all of the key files ended up "unpatched" (either because they weren't patched yet or they were successfully restored to the original version).

If any of the key files have been patched, however, that would prevent the default version identification method from "seeing" the old version. (The MD5 signatures of all of the key files must match in order for a version to be identified.)

In theory using custom scripting it would be possible to build patches that would ignore the key file restrictions if a previous patch was interrupted (which you could detect by using a semaphore of some kind, e.g. check for a value written to the registry when the patch starts, and removed from the registry when the patch ends).

Note that if the "Backup patched files" option was enabled, it should always be possible to manually restore the original files from the backups after such an event.

3. A binary file (not a key file) has been modified from the version's original state, and a patch is applied

It depends on whether the "Force install" option was enabled for that file.

If "Force install" is on, the modified file will be replaced. (The patch actually contains a full copy of that file so it can accomplish this.)

If "Force install" is off, the modified file will be left untouched. (A file can only be patched if its MD5 signature matches the original.)

[rjfioravanti]

Thanks for your reply

regarding the file that was somehow modified.. is there a way to make the patch fail if the MD5 signature does not match the original?

If a file was modified, it means somebody did something wrong... and I don't want the patch to make it look like everything went ok

Thanks!

[Lorne]

regarding the file that was somehow modified.. is there a way to make the patch fail if the MD5 signature does not match the original?

If a file was modified, it means somebody did something wrong... and I don't want the patch to make it look like everything went ok

The easiest way is to make it a key file, but in that case the version would not be identified.

Another approach would be to verify the MD5 signature from script using Crypto.MD5DigestFromFile. This could be done after identifying the version (or anywhere else for that matter).

It should also be possible to use the g_OnFileProcessed hidden function, by checking for a ResultCode of 4. (See "Miscellaneous > Hidden Functions" in the help file.)

[rjfioravanti]

It should also be possible to use the g_OnFileProcessed hidden function, by checking for a ResultCode of 4. (See "Miscellaneous > Hidden Functions" in the help file.)

So I've taken this approach which has worked quite well. Then I went to play around with it and found some surprising results. I am observing the following behaviour:

say I have versions 1, 2 and 3, and patch with target version = 3.

If I take a non-key file and edit it in version 1, then apply the patch.. it recognizes that something has been changed and aborts the way I want it to.

Now if I instead take a non-key file from version 2 and drop it in version 1 (overwriting version 1's file), I expected it to abort as well (with error code 4) because its not the expected file for version 1. However the patch seems to recognize that the file is from version 2 and patches it properly!

This works for me... is it intentional? If I decide later that I DO actually want to abort in this kind of scenario... is there a way for me to detect this? The patch log seems to just indicate success as usual.

[Lorne]

Now if I instead take a non-key file from version 2 and drop it in version 1 (overwriting version 1's file), I expected it to abort as well (with error code 4) because its not the expected file for version 1. However the patch seems to recognize that the file is from version 2 and patches it properly!

This works for me... is it intentional? If I decide later that I DO actually want to abort in this kind of scenario... is there a way for me to detect this? The patch log seems to just indicate success as usual.

If the patch was built to update 1 or 2 to 3 (i.e. all three versions were checked in the list), then yes, that's intentional.

I'm not sure if there's a way to detect that scenario generically. There are a few ways you could script it right now (e.g. check the files against a table containing all the files from different versions) but it would be a bit labour intensive, since I think you'd need to populate the tables yourself. Hmmm.