Creating System Restore Points - Thoughts?

Question

Is this a taboo for programmatically creating system restore points? I would do this before performing a software update. If there is a better way to create a recovery point with just my files and software data, let me know.

I would like to be able to return the user to a known working state if everything goes kaput during the update (closes / kills the update application, the power turns off, the user pulls out the plug, etc.)

private void CreateRestorePoint(string description) { ManagementScope oScope = new ManagementScope("\\\\localhost\\root\\default"); ManagementPath oPath = new ManagementPath("SystemRestore"); ObjectGetOptions oGetOp = new ObjectGetOptions(); ManagementClass oProcess = new ManagementClass(oScope, oPath, oGetOp); ManagementBaseObject oInParams = oProcess.GetMethodParameters("CreateRestorePoint"); oInParams["Description"] = description; oInParams["RestorePointType"] = 12; // MODIFY_SETTINGS oInParams["EventType"] = 100; ManagementBaseObject oOutParams = oProcess.InvokeMethod("CreateRestorePoint", oInParams, null); } 

Answer 1

Is this a taboo for programmatically creating system restore points?

Not. This is why the API exists; so that you can have pseudo-atomic system updates.

Answer 2

Whether this is a good idea or not really depends on how much you do. A full system restore point is significant - it takes time to create disk space for storing and adding recovery points to the interface, possibly pushing earlier recovery points out of storage.

So, if your update really only changes your application (i.e. the data stored in it, the binary files that make it up, the registry entries for it), then this is actually not a change in the system level, and I voted for no point recovery. You can emulate functionality simply by backing up the parts that you are changing, and offer a recovery option for the backup. My opinion is that System Restore should consist in restoring the system when global changes are made that can lead to its damage (application installation, etc.).

The counter argument that you just need to use the system service does not contain water for me; I am worried that if you need to release several updates for your application, the set of system restore points may become so large that important, real "system" updates may be supplanted or lost in noise.

Answer 3

No, this is not a Taboo - in fact, I would recommend it. The OS manages how many hard drives it takes, and I spent money on Microsoft, spending more money and time testing System Restore than your money and time testing your setup application.

Answer 4

If you are developing an application for Vista, you can use Transactional NTFS, which supports a similar feature for what you are looking for.

http://en.wikipedia.org/wiki/Transactional_NTFS

Will the installation packages already include rollback support of this type? I am not very familiar with most of them, so I'm not sure.

Finally, Windows, as a rule, automatically creates a recovery point at any time when you run the setup application.

Answer 5

Take a look at the following link: http://www.calumgrant.net/atomic/

The author described Transactional Programming. This is similar to database transactions.

Example:

Run transaction:

• Step 1
• Step 2
• Encounter error during step 2
• Roll back to the start of the transaction.

This is a new structure, but you can consider it more as a solution, rather than using a framework.

Using transactions, you get the “Recovery Points” that you are looking for.

Answer 6

I do not think that a full system recovery would be a good plan. Two reasons that quickly come to mind:

• Empty disk space
• Unintended Consequences of Rollback