Hi Aaron, finally found the bug. The corruption was caused by to a missing cast and resulting in an integer overflow later on. The fix will be part of the next maintenance release.
Regards, Alexander Eichner On 10.09.2014 20:01, Alexander Eichner <[email protected]> wrote: > Hi Aaron, > > thanks for the images, I’ll have a look at them. > We are definitely interested in data corruption issues but because we are a > small team with lots of work > it might take a while to get a response sometimes as we are working on other > issues. Besides, I was on vacation last week and didn’t watch > mails closely. > > I’ll see what I can find out from your images. > > Regards, > Alexander Eichner > > On 10.09.2014 19:56, Aaron Brice <[email protected]> wrote: > >> On 09/09/2014 01:35 AM, Alexander Eichner wrote: >>> Hi Aaron, >>> >>> (please keep the topic on the list) >> >> Sorry, I had unsubscribed from the list when it didn't seem like anyone was >> interested in data corruption issues.. >> >>> >>> I tested the code by writing random data to it, resizing the image and >>> verifying that the disk content didn’t changed by reading and comparing the >>> data. >>> >>> Resizing is a quick operation because VBox just relocates the data blocks >>> which would be overwritten by the extended BAT. The data blocks are >>> appended to the image file and >>> in most cases only one block needs to be relocated. If you still ave the >>> original and the broken VHD image file around can you please mail me the >>> first 5MB of each image so >>> I can have a look at them? >> >> I didn't backup the original. However, I wrote this script to resize my >> broken .vhd back down to the original size: >> https://gist.github.com/ambrice/c36b46237fcc979d80c9 >> >> I'm not 100% sure after running that script that it was back to the original >> state, for example I didn't adjust the drive geometry fields. However after >> running that, "vhd-util check" from the blktap-utils package says it's >> valid, whereas before it was complaining that "block 0 (offset 0xa3) >> clobbers headers". So I then cloned it to a .vdi and resized the .vdi and >> that worked (after running the Windows 7 repair to restore the partition >> table and boot manager). >> >> So I have a valid 40GB .vhd which may not match the original 100%, but I >> just tried to resize it to 60GB again and ran into the same problem. I ran: >> VBoxManage modifyhd AaronVM.vhd --resize 61440 >> >> It got quickly to 100% with no errors, and the file size didn't change at >> all (40766087168 bytes before and after). Attached are the first 5MB of the >> file before and after the resize. >> >> Thanks, >> Aaron >> >> <after.vhd.xz><before.vhd.xz> > _______________________________________________ vbox-dev mailing list [email protected] https://www.virtualbox.org/mailman/listinfo/vbox-dev
