Ticket #16311 (closed defect: fixed)
VBoxManage modifyhd resize needs better parameter checking to prevent catastrophic data loss
|Reported by:||mpack||Owned by:|
Please see the topic
for an example of the type of problem I'm going to discuss, however somebody makes this dumb mistake several times a year.
Scenario: they want to resize their disk, so they glance at the docs and don't notice that the resize size is in MB, therefore they provide a new size in bytes, often a very large new size. Obviously they don't make a backup either.
VBoxManage will go right ahead and attempt to create a logical drive of the chosen size * 1024*1024. Often this will fail for lack of space. Worse is when they realize their mistake and interrupt the work in mid stream. In some cases the block map alone is so huge that it won't fit on the host partition, but in all cases the most likely scenario is that their VM will not boot, and the disk contents have been scrambled.
It seems to me that VBoxManage should be doing some basic sanity checks on the resize size. This could be fancy but possibly incorrect (disk logical size can't be larger than host partition), or arbitrary - max size for resize cannot be larger than X terabytes, possibly with X depending on guest OS type. I'm sure you could dream up something sensible. But, being that it's an in-place function it definitely needs a filter for user stupidity.
Speaking of which: yeah, telling the user he should have made a backup is always good, but in that case one might wonder what the value of an "in place" method is.
No logs, since it's a design suggestion, not a crash. I set the affected version to 5.1.0, but really it's all versions since 4.0.0 to the latest 5.1.12 release.
- Status changed from closed to reopened
- Resolution fixed deleted