VirtualBox

Custom Query (16363 matches)

Filters
 
Or
 
  
 
Columns

Show under each result:


Results (2389 - 2391 of 16363)

Ticket Resolution Summary Owner Reporter
#20369 fixed Unable to download some test build files. Mario‪
Description

I am trying to download the files under development snapshots and the result is a message such as this one:

Not Found

The requested URL /download/testcase/VirtualBox-6.1.97-142300-Win.exe was not found.

#5182 invalid 'Discard Current Snapshot and State' feature is broken Mark Cranness
Description

The VirtualBox Snapshot 'Discard Current Snapshot and State' feature is broken.

1) To see the problem, perform the following steps:

  • Create a new snapshot named: '1 January'
  • Boot the VM and create a file called 'Work.txt', with this contents:

January February March (This file represents changes done over 3 months since the 1st January snapshot.)

  • Shutdown the VM. Suppose on 1 April the user wants to test an experimental change.
  • Create a new snapshot named: 'Before 1 April Experiment', intended to protect the 'Work' while the experiment is done.
  • Boot the VM and edit file 'Work.txt', adding 'Experimental change'.
  • Shutdown the VM.

Suppose the user decides that the experiment was not wanted, and they want to undo the change. They want to Revert the current state to what it was when the 'Before 1 April Experiment' snapshot was taken, and then delete that snapshot.

The VirtualBox UI provides Snapshot management buttons that can help the user unwind the change. One such button is 'Discard Current Snapshot and State'. Although the label on this button is ambigious, it seems that it will do what they want.

Hovering the mouse over this button displays the following information in the VirtualBox status bar: 'Discard the current snapshot and revert the machine to the state it had before the snapshot was taken'

Assuming the the 'current snapshot' is the most recent 1st April snapshot, then reverting the machine to the state it had before the 'Before 1 April Experiment' snapshot was taken is exactly what is required. Just before the 1st April snapshot was taken, file 'Work.txt' had January/February/March in it, representing 3 months of work.

  • Click the 'Discard Current Snapshot and State' button.
  • Boot the VM and examine the contents of file 'Work.txt'. File WORK.TXT is not present!

The 'Discard Current Snapshot and State' button has not only reverted changes since the 1st April snapshot, and removed the 1st April snapshot, but it has ALSO reverted all changes since the 1st January snapshot, and erased 3 months of work!

This is a severe bug. If this is not a bug (it is) then this is a severe design error.

(To people that might say: 'this is working as designed', I say: Rubbish! A feature that reverts back TWO snapshots is just silly and mostly useless. Why not go back 3 or more? Where is the useful feature that just goes back 1 snapshot and deletes that snapshot?)

NOTE: The 'Discard Current Snapshot and State' button acts differently depending upon if there are is ONLY ONE snapshot when it is run, or of there are 2 or more snapshots when it is run. If the above steps are repeated, but excluding the creation of the '1 January' snapshot (start from a proper root hard disk) and ensure that the ONLY snapshot present is the 1st April one, then 'Discard Current Snapshot and State' performs as expected according to the status bar information text.

2) This different behaviour can be seen in the source code (see below).

'Revert to Current Snapshot' and 'Discard Current Snapshot and State' share some source code. The (pseudo) code looks like so:

// http://www.virtualbox.org/browser/trunk/src/VBox/Main/MachineImpl.cpp?rev=13762#L8646
DiscardCurrentState() { // Implements 'Revert to Current Snapshot'
    ...
    DiscardCurrentStateHandler(false); // discardCurSnapshot=false
    ...
}

// http://www.virtualbox.org/browser/trunk/src/VBox/Main/MachineImpl.cpp?rev=13762#L8710
DiscardCurrentSnapshotAndState() { // Implements 'Discard Current Snapshot and State'
    ...
    DiscardCurrentStateHandler(true); // discardCurSnapshot=true
    ...
}

// http://www.virtualbox.org/browser/trunk/src/VBox/Main/MachineImpl.cpp?rev=13762#L9902
DiscardCurrentStateHandler(bool discardCurrentSnapshot) {
    ...

    bool isLastSnapshot = CurrentSnapshot->parent().isNull(); // Is there ONE ONLY 'last' snapshot?

    if (discardCurrentSnapshot && !isLastSnapshot) {
        DiscardSnapshotHandler(CurrentSnapshot);
    }

    RevertToCurrentSnapShot(); // inline code to do so, not a function call...

    if (discardCurrentSnapshot && isLastSnapshot) {
        DiscardSnapshotHandler(CurrentSnapshot);
    }

    ...
}

This is how the code above works...

  • 'Revert to Current Snapshot' calls DiscardCurrentStateHandler(false), so that all that happens is:

RevertToCurrentSnapShot();

  • 'Discard Current Snapshot and State', when the current snapshot has NO Parent, in other words there is ONLY one snapshot, does this:

RevertToCurrentSnapShot(); DiscardSnapshotHandler(CurrentSnapshot);

  • 'Discard Current Snapshot and State', when the current snapshot has a Parent, in other words there are two or more snapshots, does this:

DiscardSnapshotHandler(CurrentSnapshot); RevertToCurrentSnapShot();

This last behaviour is broken and unwanted and silly and inefficient.

Using the first bug example given above, which has two snaphots named '1 January' and 'Before 1 April Experiment', the call to DiscardSnapshotHandler(CurrentSnapshot) Discards 'Before 1 April Experiment', merging its changes (the 1st April experiment) with the changes stored in '1 January' (the work January/February/March). '1 January' is now the Current snapshot. Then the call to RevertToCurrentSnapShot() throws away the merged changes stored in '1 January', throwing away the experiment, BUT ALSO throwing away all of the work January/February/March, which is a severe problem. (and also, why bother merging the changes if they are only going to be thrown away?)

'Discard Current Snapshot and State', when there are 2 or more snapshots, should function exactly the same as when there is only one snapshot, and call RevertToCurrentSnapShot() first, and DiscardSnapshotHandler() second. That behaviour is useful and sensible.

3) The behaviour suggested above is useful, whereas the current 'Go back two snapshots' behaviour is mostly useless.

The suggested 'Revert to Last Snapshot then Discard Snapshot' function is useful in situations where the current state must be protected while an experimental configuration or change is done. If the experiment is successful and should be retained, the user uses 'Discard Snapshot'. If the experiment needs several iterations to get right, the user uses 'Revert to Snapshot' and tries again. If the experiment is not successful and needs to be abandoned, the user uses 'Revert to Last Snapshot then Discard Snapshot'.

#5183 invalid Better labels for snapshot Discard/Revert buttons Mark Cranness
Description

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'.

Batch Modify
Note: See TracBatchModify for help on using batch modify.
Note: See TracQuery for help on using queries.

© 2024 Oracle Support Privacy / Do Not Sell My Info Terms of Use Trademark Policy