See more on Chunks in general.
The XXXX chunk is a filler used to mark unused space within a file.
No Flags are allowed at all. So, there can be no payload specification, no continuation, etc. An XXXX chunk cannot be split (just use multiple XXXX chunks!).
The Instance Number must be 0. There can be any number of XXXX#0 chunks in an archive.
The Payload is completely ignored. The purpose of this chunk is to note a region of the file as available for allocation, so storing data here is meaningless. Since it doesn’t matter, a program can delete a chunk in the file by overwriting its header with an XXXX header, and not need to re-write the bytes forming the original chunk’s Payload.
The Checksum in the XXXX chunk is unique, using a different computation than all other chunks.
A chunk can be deleted simply by overwriting the three bytes following the size (which remain unchanged) with hex 00 00 00 (making it into XXXX#0) and updating the checksum. However, to prevent the need to read all the “don’t care” bytes of the Payload, the checksum is defined differently.
To this end, the checksum is computed over the header only, ignoring the payload bytes. That is, it will scan over the size expressed as a uintV, followed by the Type (always hex 00 00) and the Instance Number (always 0).
Empty areas smaller than 5 bytes cannot hold a chunk header, so the Fill Bytes feature is provided for this. It is not illegal for there to be a run of more than 4 fill bytes, though such a run could be replaced with an XXXX chunk. For a sufficiently long run, it is presumed that implementations will handle the XXXX chunk faster, since that area of the file may be skipped rather than read in and parsed as fill bytes.
Consecutive XXXX chunks and any XXXX chunks adjecent to fill bytes can be coalesced into a single XXXX chunk. However, it is not illegal to leave such regions un-coalesced.
When deleting chunks, the old bytes can be left unchanged in the file, to prevent the overhead of re-writing them. However, an alternative is to write all zero bytes, which for large runs can take advantage of filesystem-based compression to remove the physical storage requirement (or channel compression when transmitting it) without shortening the file by moving chunks around to fill up the hole.
Page content copyright 2003 by John M. Dlugosz. Home:http://www.dlugosz.com, email:mailto:firstname.lastname@example.org