|
|
| Forum: Link
Downloads: 25
| Submitted: Oct 21 2009
Updated: Jan 1 2013
| |
Description:
vidma is a utility for manipulating virtual disk images. It can show basic information about the image or resize it. Resizing is done by in-place modification of a file holding the image or by creating modified copy of such file.
Changelog:
* What's new in version 0.0.4 (2012-12-31)
- Unallocated blocks of zeroes are handled now properly (important for
shrinking dynamic images). Bug discovered thanks to Romain Guinot.
- Non-zero extra blocks are supported now.
- Upcoming image size change is shown before the resize operation, along
with the required free space for the operation and free space that is
available on the volume at this moment.
* What's new in version 0.0.3b (2011-10-13)
- Messages printed by vidma have been slightly changed.
- Simple configure script has been added. You have to run it before invoking
make. Building outside of the source directory is now supported.
* What's new in version 0.0.3a (2011-02-28)
- Manual page has been added.
* What's new in version 0.0.3 (2011-02-26)
- Resizing dynamic VDI files is finally supported!
First expanding will (almost) always move blocks, but next ones will do it
only if you cross 255 GB boundary, and again for ~512 GB, etc. In future it
will be fixed, i.e. all block moving will be avoided for second and further
resizes if block size equals multiple of 1 megabyte (I haven't seen any
image "breaking" this rule in the wild, but it's possible).
Even shrinking is possible, but only if does not involve discarding of
allocated blocks. In future it will be also fixed with implementation of
block linearization.
* What's new in version 0.0.2 (2011-02-22)
- Many restrictive assumptions about supported VDI files has been removed.
Images created in VirtualBox 4.x should work fine now. Still only fixed
ones can be resized.
- Before resizing user gets information about upcoming operation and question
whether it should be really performed.
- Resizing strategy has been changed. Old one was almost always moving blocks,
which is simply stupid and inefficient. Now if data offset can be preserved,
i.e. there is enough space for block allocation map, block moving will be
avoided. If it cannot be avoided, then new data offset will be aligned to
megabyte. It nicely prevents from moving blocks in possible future resizes
(unless you cross 255 GB boundary).
- Running in Windows 2000 is possible now.
* What's new in version 0.0.1 (2009-10-21)
- Nothing, it's just the first public version.
License: GPL
|
| |
Add commentBack
|
