linearize-data.py hangs on any block file that ends in zero padding.
Reproduce:
mkdir -p /tmp/lin/blocks && cd /tmp/lin
python3 -c "open('blocks/blk00000.dat','wb').write(bytes(4096))"
printf '%064d\n' 0 > hashlist.txt
printf 'input=blocks\nhashlist=hashlist.txt\noutput_file=bootstrap.dat\ngenesis=%064d\n' 0 > linearize.cfg
python3 /path/to/bitcoin/contrib/linearize/linearize-data.py linearize.cfg
Before, it never returns:
Read 1 hashes
Input file blocks/blk00000.dat
<hangs>
After:
Read 1 hashes
Input file blocks/blk00000.dat
Input file blocks/blk00001.dat
Premature end of block data
Indexing a bytes object returns an int in Python 3, so inhdr[0] == "\0" is always false and the zero-padding check never fires. The script instead falls through to the magic-bytes search, which advances one byte per iteration; at the end of the file read(8) returns 7 bytes and seek(-7) moves back to the same offset, so it loops there forever and the Premature end of block data path is never reached.
Block files are preallocated in BLOCKFILE_CHUNK_SIZE (16 MiB) chunks and only truncated once finalized, so the most recent blk*.dat normally ends in padding.
This is reached whenever the hashlist references blocks that are not in the blocks directory. The most common case is a pruned datadir, which the script explicitly supports - getFirstBlockFileId() starts at the first surviving blk file for exactly that reason. The intended response is "Premature end of block data", but that path is never reached.
This is the same one-line change as #32978, which was closed because no reproduction was provided. Happy to add a test to test/functional/feature_loadblock.py instead if that is preferred.
