Differencing disk corruption

Mar 1, 2010 at 5:59 AM
Edited Mar 1, 2010 at 6:03 AM


I've been trying to track down corruption I see in differencing disks (using the .8 preview release).  When I create a base disk and then create a differencing disk on top, as soon as any write occurs to the differencing disk the file is corrupt (Windows reports the file is corrupt or damaged).  NTFSDump blows up on the file (while VHDdump does not).  What I see is the first block after the bat is overwritten, however that block (and the next one) contain the differencing disk absolute and relative paths.  The absoluate path block is being overwritten, it does not appear the relative block one is. I beleive I've tracked the issue down, but I would like some advice on the correct fix.  In DynamicStream.cs:

private void ReadBlockAllocationTable()

if (lastBlockStartSector == 0)
    // No blocks allocated yet, so infer it's at the end of the BAT
    _nextBlockStart = Utilities.RoundUp(_fileStream.Position, Utilities.SectorSize);

_nextBlockStart gets set to right after the BAT but that block contains the absolute path information for the differencing disk.  Later in AllocateBlock()...

long newBlockStart = _nextBlockStart;

// Create and write new sector bitmap
byte[] bitmap = new byte[_blockBitmapSize];
_fileStream.Position = newBlockStart;
_fileStream.Write(bitmap, 0, _blockBitmapSize);

Does the actual overwrite.

Clearly _nextBlockStart needs to be adjusted, but I'm just getting upto speed on the code and am unclear on the correct fix.  It seems that the parent locators need to be looped thru and the highest one taken (+512) as the initial start location when no blocks are allocated. Could you take a peak?


Mar 1, 2010 at 9:56 PM

Thanks Bill - looking at it again, this was a misguided attempt to avoid an extra sector read.  I've checked in a change that instead will tack new blocks on the end of the file, as the 0.7 release did.