Better labels for snapshot Discard/Revert buttons

[Mark Cranness]

The labels on the snapshot buttons are confusing and ambigious.

1) Here's the short version:

1a) Relabel 'Revert to Current Snapshot' to:

Revert to Last Snapshot

1b) Relabel 'Discard Current Snapshot and State' to:

Revert to Last Snapshot then Discard Snapshot

1c) Relabel 'Discard Snapshot' for the last ('current') snapshot to:

Discard Snapshot, Keeping Current State

1d) Relabel 'Discard Snapshot' for other than the last ('current') snapshot to:

Discard Snapshot, Keeping Changes

... and while we're at it...

1e) When the last ('current') snapshot is selected, enable these buttons also:

Revert to Last Snapshot Revert to Last Snapshot then Discard Snapshot

(... why force the user to stumble around the UI looking for the correct option? Just because they have selected the last snapshot rather than the Current State is no reason to disable the two buttons above.)

1f) Consider changing the 'Revert to Last Snapshot then Discard Snapshot' button icon. Rather than a double up-arrow, how about a single up-arrow and a cross-delete, because this combines the functions of Revert and Discard?

1g) Until such time as the snapshots handle a BRANCHED tree, replace the tree with a simple vertical list.

The axis for snapshots is TIME. A tree, ever wandering off to the right of the screen, is just silly (until VirtualBox handles branched snapshots that is).

2) Longer version, and justification for the above:

2a) 'Revert to Last Snapshot'

One likely reason for the confusing labels is because there is a disconnect between the objects that the VirtualBox developers work with, and the objects / conceptual 'model' that users expect to see.

VirtualBox developers deal with these objects:

• Snapshots.

• Snapshots store FORWARD differences between that snapshot and the next snapshot.

• Snapshots 'work' by protecting the base virtual HD and all of the previous snapshots, by providing a place to store changes to the VM. With all ongoing changes stored in the snapshot differences, those changes can be undone simply by abandoning the snapshot.

• The LAST snapshot is the snapshot that stores changes to the current state of the VM. In that sense, the LAST snapshot is also the CURRENT snapshot.

Some of the concepts that a VirtualBox developer understands (above) are not applicable to the UI displayed to the end user. (Unfortunately, some of those concepts have creapt into the UI.)

Users (should) deal with these objects / imagine this 'model' in their heads:

• Snapshots.

Snapshots are logically a complete copy of the entire state of the VM at the time the snapshot was made

• Changes.

Between each snapshot, the VM state changes. These changes might be stored in the next snapshot as BACKWARDS differences, or they might be stored in the previous snapshot as FORWARD differences, but the user should not have to worry about this implementation detail (I suggest).

• The Current State.

The last/most recent/current state (configuration, contents of disks, etc.) of the VM.

With '-' indicating a point in time, and '>' indicating the passage of time, the snapshot history for an example with 3 snapshots might look like the following to the user: (I mean in their mind, this is the 'model' they have of how the snapshots work.)

• Base disk
• Snapshot 1

  Changes between snapshot 1 and 2

• Snapshot 2

  Changes between snapshot 2 and 3

• Snapshot 3

  Changes between snapshot 3 and the Current State

• Current State

They may not conciously think about the Changes, and instead just consider the snapshots and the current state.

Note, in the user's mind:

• There is no CURRENT snapshot, but there is a LAST snapshot (= Most Recent).

Consider an example where the three snapshots above were done 1-January, 2-January and 3-January, and it is now November. Is one of those January snapshots 'CURRENT'? Not in the mind of the user. The word 'Current' should not be used to describe snapshots. Instead 'Last' should be used (or when the branched snapshot tree eventually arrives: 'Parent').

Thus: 'Revert to Last Snapshot'

2b) 'Discard Current Snapshot and State' -> 'Revert to Last Snapshot then Discard Snapshot'

Users may be familiar with using the snapshot 'Discard Snapshot' menu to remove snapshots. Past experience has taught them that the 'Discard Snapshot' feature only deletes the snapshot, BUT the CURRENT STATE is retained. Suppose, intending to discard the last snapshot, BUT RETAIN the current state, they click on Current State in the tree (for whatever reason). Button 'Discard Current Snapshot and State' is enabled. On the face of it, that seems to be the same as 'Discard Snapshot', or very similar... There is the extra '... and State' on the end, but WHAT STATE? They think: "perhaps the last snapshot has some mysterious internal State associated with it?" It doesn't say 'Current State', so I should be safe?

They click it, intending only to delete the snapshot, but instead end up Reverting the current state also.

'Revert to Last Snapshot then Discard Snapshot' emphasises the main function of this feature (Revert).

(But that feature doesn't work that way I hear you say?: viewtopic.php?f=9&t=23249)

2c) Discard Snapshot, Keeping Current State

The current label only tells half the story about what this feature does, which can lead users to make the wrong choice.

Suppose a user takes a snapshot, makes an experimental change and then decides to abandon the change, and the snapshot. Perhaps not sure what button to use to undo the experiment and delete the snapshot, but knowing that they must revert back to the last snapshot, they SELECT THE LAST SNAPSHOT. A button is then available: 'Discard Snapshot' They know they want to discard the snapshot, but they ALSO want to revert the changes. The button does not make it clear what will happen to the current state. They think: Anyway, Discard that snapshot is what I want to do... They click the button and end up NOT reverting their changes, but instead RETAINING their changes.

2d) Discard Snapshot, Keeping Changes

The current label only tells half the story about what this feature does, which can lead users to make the wrong choice.

• 'Keep'/'Keeping' versus 'Merge'/'Merging'

When Discarding a snapshot, the changes either side of it (preceeding it and following it) must be merged. Because in VirtualBox the changes are stored in the older snapshot, as Forward differences, the changes must be merged into the PREVIOUS snapshot.

But consider a different way that a user might think about the differences: They may be familiar with incremental file-system backups, or an incremental database backup (backing up a SQL Server transaction log which clears the log). In those cases the 'differences' stored in the 'backup', or 'snapshot' (the backup could in sosme way be consider to represent a snapshot), are BACKWARD differences, in that they are the changes that happened BEFORE the backup was made. Hypothetically, If one of those backups/snapshots were to be discarded, the changes would have to be merged into the FOLLOWING backup.

For this reason, I suggest it is preferable to NOT make a distinction of which DIRECTION any differences are merged (to the PREVIOUS snapshot or to the FOLLOWING snapshot). (MUST the differences/changes be associated with the previous snapshot IN THE UI? I suggest not, i.e. DO NOT mention merge direction in the UI.)

Mentioning 'Merge' at all in the UI raises the question of "Merge what with what?", and is a technical / internal issue that the user probably needn't be bothered with.

I suggest that '...Keeping Changes' tells the user about the most important fact about the changes, without 'opening the merge can-of-worms'.

[Mark Cranness]

Also in forum: ​http://forums.virtualbox.org/viewtopic.php?f=9&t=23251

[Sander van Leeuwen]

You've written a complete essay about the subject, but from a quick look it seems you made a few mistakes.

Look at the following scenario: (read-only base image)

• snapshot 1 -> contains state and differencing disk image to store changes with the base image
• snapshot 2 -> contains state and differencing disk image to store changes with the diff image of snapshot 1
• snapshot 3 -> contains state and differencing disk image to store changes with the diff image of snapshot 2
• current state; either snapshot 3 or the state (diff image only) that reflects the machine when you powered it off and didn't revert back to snapshot 3

If you discard snapshot 3 and its state, then you delete the state and diff image files. The end result is a change of the current snapshot to snapshot 2 if snapshot 3 was the current state. If it wasn't, then the diff image is merged into the diff image of the current state (forward merging).

If instead you discard snapshot 2, then you delete its state and merge the diff image into snapshot 3 (forward merging).

If instead you discard snapshot 1, then you delete its state and merge the diff image into snapshot 2 (also forward merging).

If only snapshot 1 is left and you discard it, the you merge the diff file into the base image (backward merging). The state of snapshot 1 is then turned into the current state (= saved state).

I agree that in this area the GUI leaves a lot to be desired, but we are working on branched snapshots as we speak. Changing the GUI twice is not very productive. Instead we'll revise the entire naming scheme when branching snapshots are finished.

[Sander van Leeuwen]

The thing to keep in mind is that whenever you restore a snapshot and start the machine, we immediately create a new differencing image to store any changes you make during the session. If you create a new snapshot, this current diff image (+ the current VM state) is saved as a snapshot.

By VM state I mean the contents of guest RAM, internal VM state and states of all virtual devices. I mention the differencing image separately, because there might be none if you boot from an ISO for instance and have no attached disks.

[Sander van Leeuwen]

Well, now I made a mistake myself. Comment 2 is only correct when the base image is read-only. If it's writable (default behaviour), then your description is correct:

• snapshot 1: VM state; no differencing image as the base image contains the right state
• snapshot 2: VM state + diff image with changes to base image
• snapshot 3: VM state + diff image with changes since snapshot 2

Discard snapshot 3 + state: deletes state and diff image files.

Instead discard snapshot 2: merge diff image with snapshot 3 (forward merging); delete VM state.

Instead discard snapshot 1: delete VM state.

[Mark Cranness]

1) Please consider my button relabeling suggestions as part of the branched snapshots.

2) I don't think I have made a few mistakes, but please help me understand how this works (this point is off-topic to my ticket).

I am sure that snapshots contain forward differences images that record changes since the snapshot was made. As a test, I created a snapshot, noted the file sizes and dates: Main VDI in HardDisks folder: 19MB 12:31am, snapshot: 9KB 12:32am, then copied a large (5.5MB) file to the disk. The HardDisk stayed the same size and date and the snapshot VDI file increased to 9.2MB 12:37am. Further files copied also increased the size of the snapshot. I took a second snapshot, which stared out as 9KB 12:39am. Copying more files, and the second snapshot file increased in size, but the main HD and the first snapshot file stayed the same same size and date.

Your third comment indicates that snapshots contain backward differences since the previous snapshot, which I do not believe is the case. In your scenario, where are disk differences for the current state stored? You have snapshot 1 with no difference image, snapshot 2 with the difference image for changes between the base (=snapshot 1) and snapshot 2 and snapshot 3 with diff images since snapshot 2.

This should be:

• snapshot 1: VM state @1 + difference image for changes since snapshot 1
• snapshot 2: VM state @2 + difference image for changes since snapshot 2
• snapshot 3: VM state @3 + difference image for changes since snapshot 3 (=Current State)

Looking at the source code supports the idea that the differences are forward differences, and are merged backwards when a snapshot is discarded (lines 134 thru 161 of SnapshotImpl.cpp : ​http://www.virtualbox.org/browser/trunk/src/VBox/Main/SnapshotImpl.cpp?rev=13762#L134)

[Sander van Leeuwen]

Do not confuse a snapshot with the current state. Snapshots are static; the current state is dynamic. If snapshot diff images were changed, how could we restore them?

Diff images always contain the changed blocks compared to the parent in the chain; i.e. a backward references + collection of changes to the parent at the moment of snapshot creation.

When you restore snapshot 1, then we automatically create a new diff image for the current state. When you copy new files, this new diff image grows in size. The snapshot remains unchanged. These changes are lost when you power off the VM and revert to snapshot 1.

This new diff image will become snapshot 2 once you create it.

[Mark Cranness]

My brain has exploded, but all of the bits landed in a neat pile... ;-)

You are of course right, and my "This should be" scenario is wrong. (Thank you for your patience.)

That sometimes the merge happens forwards and sometimes backwards is another reason not to mention "merge" or merge direction in the UI.

[Mark Cranness]

After some more thought, I think the labels for 'Discard Snapshot' for all but the last ('current') snapshot should stay as it is (best not to mention changes/merge/differences hard disks in the UI at all). The labels would then be:

• Revert to Last Snapshot
• Revert to Last Snapshot then Discard Snapshot
• Discard Snapshot, Keeping Current State
  (for the last ('current') snapshot)
• Discard Snapshot
  (for other than the last ('current') snapshot)

BTW: Forum discussion @ ​http://forum.virtualbox.org/viewtopic.php?f=9&t=20853

@Sandervl: I had somehow got it into my head that the difference hard disks were stored in the n-1 snapshot, rather than the n snapshot, moving all of the difference hard disks up/back by 1 position (and the machine "current state" difference hard disk moved into the last snapshot). It all seemed to work (in my head) pretty much the same as it actually does, because the same difference disks were still there, just stored in different snapshots (and forwards merge became backwards merge). Thanks for correcting me.

[Sander van Leeuwen]

Thanks for the report, but we're going to redesign the whole thing as the current implementation is, ehm, not ideal. Therefor it doesn't make any sense to open tickets anymore. Please wait for the next major release.

In the new design there will be two operations:

- delete snapshot
- restore snapshot (any in the tree)