why you named my name ... connected to the lousy screenshot ... which includes a ... lousy icon ....
I think you answered your own question.
Your comparison of VHD format with ZIP is interesting, though some - not so trivial - details must be specified.
There are three types of VHD's:
The first type is nothing but a RAW disk image with a single description sector appended to it.
There are three sub -cases for it:
- the disk image is "filled to the brim" by one (or more) partition(s)
- there is some "unused space" at the end of it
- there is some "unused space" after the MBR and before the PBR of first partition (with the exception of the "normal" 62 or 2047 hidden sectors), as an example you create two parittions on the disk and later you delete first one.
Originally I was going to analogy of a ZIP file made with the "Store" option (no compression what-so-sever) and some 1920x1200 true-color BMPs that were entirely black. But I wanted to keep it simple.
You could (however) compress those giant black BMPs down to next to no size, had you not been a total doofus at the time you made the ZIP.
And again, it's not the problem of the ZIP program to deal with doofus related errors
In case 1.1 (probably 99% of commonly used VHD's) there is no possible way to reduce the size of the image file without touching the inner partition data.
In case 1.2 it is trivial to truncate the image after the last sector used and re-add the footer
In case 1.3 there is no possible way to reduce the size of the image without touching the inner partition data.
I would agree, with you there. Re 1.2 - Given the VHD specification is in the public domain, it probably is quite trivial to truncate and change a few bytes. And I allow for that in my closing statement about "if there is an easy hack".
I am not familiar with Dynamic or Differencing VHD's, but if you don't touch their contents I doubt that you can in any way reduce their size.
I would have agreed with you before today, but reading the MSDN document (which I pasted above a few post up), apparently you *can* compress differencing VHDs.
If I may introduce some anecdotal here-say: I heard someone suggest that differencing VHDs grow in such a way, that seems to indicate they are more of a "log of disk writes".
The example cited, was that if you start with an empty differencing VHD, and add a 1GB file, the VHD will be 1GB.
If you delete the 1GB file, the VHD will still be 1GB
If you overwrote the 1GB file with another 1GB file, the VHD would be 2GB.
I assume that if you ran a 13 pass file eraser over the file, that would mean you had a 14GB VHD.
Hence: compressing differential VHD files is a WMI option for VHD manipulation.
Certainly, I can't think of any other way you'd be able to optimize a differential VHD.