[mtrossbach]

mcTempDropTail() clears the counter value of every block that a truncate keeps behind the end of a temporary file, but only if all 8 bytes of the counter are kept. With a chunk size that is not a multiple of 8, the rounded truncate can keep only a part of the counter of the next block. That part survives, and when a later write leaves the block out, the block reads as keystream instead of zeros. Now every block whose counter starts before the physical end is cleared. Writing the 8 zero bytes extends the file by at most 7 bytes, which belong to a zero counter.

SQLite itself sets a chunk size only for sorter files (4096), which does not trigger this; it takes an application that sets such a chunk size for a temporary file.

tempfiletest checks this once at the start: with a chunk size of 4108, a truncate to one block keeps half of the counter of the second block, and after a write to the third block the second one must read as zeros. The check runs on the VFS below the spy, because the spy itself sits on the Multiple Ciphers VFS, so the chunk size of the file under test does not reach the file on disk.

Testing (macOS arm64, flags from Makefile.am):

• The new check fails on 5a9d89f in all four tempfiletest runs of the CI and passes with the fix.
• The SQL scripts from the CI, cryptotest, the four tempfiletest runs, oomtest and rekeytest pass.
• tempfiletest built with SQLITE3MC_ENCRYPT_TEMP_FILES=0 passes (the check is skipped there).