aboutsummaryrefslogtreecommitdiff
path: root/util
diff options
context:
space:
mode:
authorJeff Cody <jcody@redhat.com>2014-05-13 10:00:52 -0400
committerKevin Wolf <kwolf@redhat.com>2014-05-19 11:36:48 +0200
commit6906046169ffa9d829beeeaafe1fadeba51669fb (patch)
tree0d079e9809a4b1bc403d8e1e5c9a52d26120b6a5 /util
parent395071a76328189f50c778f4dee6dabb90503dd9 (diff)
downloadqemu-6906046169ffa9d829beeeaafe1fadeba51669fb.zip
qemu-6906046169ffa9d829beeeaafe1fadeba51669fb.tar.gz
qemu-6906046169ffa9d829beeeaafe1fadeba51669fb.tar.bz2
block: vhdx - account for identical header sections
The VHDX spec v1.00 declares that "a header is current if it is the only valid header or if it is valid and its SequenceNumber field is greater than the other header’s SequenceNumber field. The parser must only use data from the current header. If there is no current header, then the VHDX file is corrupt." However, the Disk2VHD tool from Microsoft creates a VHDX image file that has 2 identical headers, including matching checksums and matching sequence numbers. Likely, as a shortcut the tool is just writing the header twice, for the active and inactive headers, during the image creation. Technically, this should be considered a corrupt VHDX file (at least per the 1.00 spec, and that is how we currently treat it). But in order to accomodate images created with Disk2VHD, we can safely create an exception for this case. If we find identical sequence numbers, then we check the VHDXHeader-sized chunks of each 64KB header sections (we won't rely just on the crc32c to indicate the headers are the same). If they are identical, then we go ahead and use the first one. Reported-by: Nerijus Baliūnas <nerijus@users.sourceforge.net> Signed-off-by: Jeff Cody <jcody@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Diffstat (limited to 'util')
0 files changed, 0 insertions, 0 deletions