Running core 0.10.2 here - just on and off - to get hold of the whole blockchain. Still ~42 weeks behind. Anyway I'm trawling through the blk00xxx.dat files with a python script, and I find that part way into my blk00065.dat, there's a long string of zeroes. 249209 bytes to be precise. They start just after the end of a previous block, where my python script is obviously expecting to see 0xF9BEB4D9. After them, I do indeed get the magic bytes and it appears the blockdata resumes as normal.
Skipping zeros is the expected behaviour. In fact, you are supposed to skip any data you find until you hit the magic pattern. Random data would work too (as long as it didn't contain the magic pattern).
Bitcoin core preallocates the blk*.dat files in large sections. I am not sure what the size is, but assume it is 16MB. When core creates a new blk*.dat file, it allocates 16MB of all zeros. It then overwrites the zeros as new blocks arrive. If there isn't enough space for new blocks, it allocates another 16MB of zeros at the end of the file.
Eventually, it reaches the threshold for the file size (2GB) and moves to the next file. The final section of the file is left with any zeros that weren't overwritten with block data.
This method reduces file fragmentation. The smallest allocation for the file is 16MB.
I didn't realise that it left zeros in the middle of a file though. What probably happened was that you shutdown the program, so there was zeros left at the end of the file. When it started again, it started a new section and those zeros were left and never overwritten. This saves it having to scan the file to find where the last block ended.
Does the section of zeros end at an even location (like 1MB aligned)?
