Updating Rollback and keeping snapshots is impossible....I think not!

[carfal]

Nick10, thankyou for your reply and explanation on the subject. However, I'm not sure why Rollback cant be designed to have a snapshot contain all of the Rollback files necessary to make this snapshot an independant or good snapshot for integrities sake. What im saying is, why cant i have say v9 running in a current snapshot then upgrade to say v9.1 and take another snapshot. Now i have an older snapshot containing v9 and a newer one containng v9.1

In doing so i fully expect that when i Rollback to the older snapshot then v9 will be running and if i Rollback to the later snapshot v9.1 will be running. Because each snapshot is isolated (one of Rollback's strong suites) then I dont see the issue here. The file table format that Rollback uses will presumably stay the same with these minor updates? You said something about having to open a window to update all the older shapshots and therefore creating vulnerability. With my above understanding this simply will not be necessary.

The one thing I'm not considering in all of this is how the subconsole comes into play and if the subconsole is the one component that has to be shared amongst all snapshots. Because of this i dont know if you can have snaphots containing different versions of Rollback. But even in this case, cant you then program the subsonsole to take a peek into the snaphot or mark each snapshot with what version it was taken with so that it can work with whatever version of Rollback is installed? Of coarse if the subconsole is also part of the snapshot then all this is not an issue is it?

I hope you dont mind me harping on about it but it seems to me that its a feature that at the moment seems to be a very serious draw back for many users including me. Perhaps in the end a compromise can be established where by you have a choice of upgrading along with all the warnings and a complete uninstall and reinstall if you so desire for a Rock solid result.

Again, thankyou for your input Nick10

[devteam]

Hi Carfal,
To answer your question, Rollback Rx has three main components:
1. The subsystem which loads before Windows O.S. and is shared by all snapshots.
2. The device drivers which are Windows kernel drivers and are loaded by Windows O.S.
3. The registry settings, user mode applications for the program UI (the tray icon, the program interface and other DLLs) which are run by users.

Let us say we setup Rollback v8.0 on a PC and take two snapshots: S1 and S2.

We then upgrade Rollback to the latest v9.0.
During the upgrade, we will:
1. Update the subsystem. Not easy, but can be done.
2. Update the kernel drivers. Can be easily done. Replace the files and reboot.
3. Update the registry settings and user mode applications. Can be easily done. Just replace the files.
At end of the upgrade, we take a new snapshot S3. So the snapshot S3 has the v9.0 subsystem, v9.0 drivers and v9.0 registry settings. Everything is good.

But when a user rolls back the PC to snapshot S2, we will have v9.0 subsystem, v8.0 drivers and v8.0 registry settings/program files.
Why? Because by definition, a snapshot is exactly what you have at the time of the snapshot. At the time of snapshot S2, the Rollback drivers and registry settings are v8.0. And if the user takes a new snapshot S4 based on the S2, the S4 will have v9.0 subsystem, v8.0 drivers and v8.0 registry setting/program files.
So we end up with snapshots S3 with v9 subsystem, v9 drivers and v9 registry, but snapshot S1, S2 and S4 with v9 subsystem, v8 drivers and v8 registry. This will be a mess after a while…

So how can we also upgrade the drivers and windows registry setting in snapshot S1 and S2 to v9?

One solution is that when we are upgrading to v9.0, we open up snapshots S1 and S2 and update the driver files and registry settings in the snapshots.
First, this would violate the principal of snapshots – snapshot contains everything at the time of the snapshot. At the time of taking snapshot S2, the drivers and registry settings are v8.0. When you restore to it now, it becomes v9.0…
Second, this is a very difficult and risky job. It’s easy to update the drivers because they are just files. But Windows registry settings are stored in several database files. When we open up snapshot S2, we can only access the registry in the format of database files. To crack the registry database files open and modify those registry settings is very risky.

The other solution is to fake the file updates to snapshots S1 and S2.
Instead actually updating the drivers and registry settings in snapshots S1 and S2, we store the v9 drivers and registry setting in the subsystem.
When user rolls back to snapshot S2, as soon as the Windows loads up, we automatically run an upgrade program that retrieves the drivers and registry settings from the subsystem and replace them over the existing files in snapshot S2.
So at the end, it appears after you have rollback to snapshot S2, you have v9.0 subsystem, v9 drivers and v9 registry settings.
Nick10 mentioned above that we provided a custom version to a customer, that allows upgrade with snapshots intact.
This is how we did it.
But we found out from customer feedback, this maneuver is very risky too.
This is how the process works when rolling back to snapshot 2:
1. V9 subsystem loads. 2. Windows starts up. 3. Windows loads the v8.0 kernel drivers during startup 4. Logging into Windows 5. The upgrade program retrieves the v9 drivers and registry files from the subsystem and update them in snapshot S2.
Notice the upgrade actually happens after we load up the system with v9 subsystem and v8 drivers…this is where all the uncertainties come from.
If there are two much changes between the subsystem and the drivers, we could have a BSOD while the drivers load.

After evaluating all the options, we think the current upgrade strategy is the safest and easiest. You know everything is possible in programming, it’s all about rewards and risks. In our eyes, upgrading rollback and keep all snapshots intact is nice to have, but it just doesn’t justify the risks

[carfal]

DevTeam. Thankyou for that excellent explanation of the complexities of upgrading Rollack. I really enjoyed reading that.

Clearly, upgrading and keeping old snapshots have the potential to become very messy in the long run. Having said that, I'm going to take the liberty of bouncing around a couple of ideas with you guys if thats OK.

But when a user rolls back the PC to snapshot S2, we will have v9.0 subsystem, v8.0 drivers and v8.0 registry settings/program files.
Why? Because by definition, a snapshot is exactly what you have at the time of the snapshot. At the time of snapshot S2, the Rollback drivers and registry settings are v8.0. And if the user takes a new snapshot S4 based on the S2, the S4 will have v9.0 subsystem, v8.0 drivers and v8.0 registry setting/program files.
So we end up with snapshots S3 with v9 subsystem, v9 drivers and v9 registry, but snapshot S1, S2 and S4 with v9 subsystem, v8 drivers and v8 registry. This will be a mess after a while…

In this scenario, would it be possible to have the v8 subconsole and v9 subconsole side by side which would require a third new module deciding which subconsole to use to boot with?

So how to handle which snapshot contains which version of Rollback so that the user can clearly see it. Simply add a new column in the "Snapshot history" window (and anywhere else its required) saying V8.0 or v9.1 etc.

Now you guys are probably going to say "Yes but this will mean eventually you'll have 3,4,5 versions of Rollback consoles in the MBR" (or where ever you decide to put them).

To avoid this, i suggest having a limit of 2 different versions of Rollback installed at any one time (more if its possible). At this stage the installer will ask which version you want to remove. You choose. The relevant snapshots are removed. Relevant subconsole removed. New subconsole added...and so on and so on. I'm sure you get the picture better than me.

OK. Now please reply with "Thats a fantastic idea!"

Or shoot me down with "Cant fit that much data in MBR"

EDIT: BTW Merry Christmas everyone!

[Dallion]

I notice that Comodo TM forces you to unistall Truecrypt if you have it installed.
Presumably this is because Truecrypt allows you to encrypt whole partitions of even the system drive, and CMT can't handle this.
But Truecrypt can also be used to encrypt single files or folders, which shouldn't cause any problems.
Truecrypt certainly works OK with Rollback Rx using an encrypted non-system partitition. (I haven't tried it with an encrypted system partition).

It seems a bit over the top that Comodo force you to uninstall a very useful utility so you can't encrypt a file with Truecrypt and use CTM at the same time.

So I'm sticking with RB, thank you very much!