0

I had hoped that applying and then deleting a CheckPoint would result in all changes since the CheckPoint being discarded, but unfortunately this has proved to not be the case.

Here's what I did with the Win8.1 VM, all while signed in via RDP:

  1. Created a CheckPoint
  2. Created a text file on the desktop
  3. Applied the CheckPoint (was disconnected, had to sign in again)
  4. Noted after signing in that the file was gone (so far, so good)
  5. Deleted the CheckPoint
  6. Noted in Hyper-V Manager that a Merge process automatically initiated
  7. The text file magically reappeared on the desktop (unwanted state)

This would seem to indicate that CheckPoints aren't a reliable means of rolling back to a previous state after a failed software installation, etc.

If this is the case, how can we get to that previous state and clean up after ourselves when we're done?

2 Answers 2

2

I'm leaving this question active in case someone finds it who happens to have made the same mistake I was making.

In Step #7 above, the file didn't reappear because the CheckPoint deletion somehow merged in the unwanted state. It reappeared because this is a domain-joined OS using Folder Redirection and I was doing all of this on the Desktop. The file was being restored from the server.

Once I did all of this in a folder on the local drive (e.g. C:\_Test) it worked as expected.

1

By applying the checkpoint, you forked the timeline of your VM. Then you deleted one of the two forks. Unfortunately, you deleted the fork that you wanted, rather than the fork that you didn't want. It's possible to delete either fork.

1
  • I'm not sure I follow you. The only nodes in the CheckPoint TreeView are the CheckPoint itself and Now. There's no option to delete Now.
    – InteXX
    Jul 7, 2016 at 20:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .