How 7-Zip Handles Corrupted Central Directories

When a ZIP archive suffers damage to its central directory, standard extraction utilities often fail completely because they rely on this end-of-file index to locate and unpack contents. 7-Zip distinguishes itself by employing a robust fallback mechanism that scans the physical file structure from the beginning, attempting to locate individual local file headers when the central directory is unreadable or truncated. This article explains how 7-Zip detects central directory corruption, the recovery methods it uses to retrieve accessible data, and the technical limitations encountered during this process.

The Role of the Central Directory in ZIP Archives

In a standard ZIP archive, individual files are stored sequentially, each preceded by a Local File Header (LFH) containing basic metadata and compressed data. At the very end of the archive sits the Central Directory, finalized by the End of Central Directory (EOCD) record.

The Central Directory serves as the master table of contents. It stores critical metadata, including exact file names, compression methods, relative offsets to each LFH, timestamps, file attributes, and CRC32 checksums. Because reading this table allows instant random access without parsing the entire file, ZIP extractors default to reading the EOCD first.

How 7-Zip Detects Corruption

When opening an archive, 7-Zip follows standard protocol by seeking the EOCD record near the end of the file. Corruption is flagged if:

  • The EOCD signature (0x06054b50) cannot be located within the expected search range (typically the last 64 KB of the file).
  • The central directory records are malformed, contain invalid byte lengths, or point to offsets outside the archive boundary.
  • The file is truncated, meaning the download or transfer terminated before the central directory was written.

Most default archive utilities (such as Windows built-in ZIP support) abort at this stage with errors such as "The compressed folder is invalid or corrupted."

7-Zip’s Fallback: Linear Signature Scanning

Unlike basic extraction tools, 7-Zip does not immediately declare the archive unreadable if the central directory fails verification. Instead, it switches to a sequential scanner mode:

  1. Header Hunting: 7-Zip reads the archive from byte zero onward, scanning for the 4-byte signature corresponding to Local File Headers (0x04034b50 or PK\x03\x04).
  2. Metadata Extraction from LFH: Whenever a valid header signature is identified, 7-Zip reads the local metadata, which includes the file name, compression format (such as Deflate), compressed size, and uncompressed size.
  3. Stream Boundary Calculation: Using the specified compressed size, 7-Zip identifies where the payload ends and attempts to locate the next local header signature immediately following it.

This process allows 7-Zip to reconstruct a virtual directory tree directly from the raw payload streams, enabling users to browse and extract files even if the entire end of the archive is missing.

Error Notifications and Warnings

When 7-Zip successfully reconstructs an archive via signature scanning, it notifies the user of the underlying integrity issues rather than hiding them. In the 7-Zip GUI, the archive may open with a "Headers Error" warning. During extraction, files with intact local headers and valid payloads will extract normally, while partially damaged streams will trigger "Data error" or "CRC failed" alerts on a file-by-file basis.

Limitations of Local Header Recovery

While 7-Zip's fallback mechanism recovers data that other tools cannot, this approach has specific technical constraints:

  • Data Descriptors (Streaming ZIPs): Some ZIP archives are created via a streaming process where compressed size, uncompressed size, and CRC are unknown when writing the LFH. In these cases, bit 3 of the general purpose flags is set, and the sizes in the LFH are listed as zero; the actual dimensions are written after the compressed data in an optional Data Descriptor record. When the central directory is lost on such archives, 7-Zip cannot easily determine where the compressed stream ends, making sequential recovery significantly more complex or impossible.
  • Missing Extended Metadata: Certain file attributes, extended timestamps, NTFS security descriptors, and full folder hierarchies may only be preserved inside the Central Directory. Recovered files may lose their original directory structure and end up unpacked into a flat directory.
  • ZIP64 Records: If an archive exceeds 4 GB or contains more than 65,535 files, the missing or corrupted central directory can prevent 7-Zip from determining proper 64-bit offsets, potentially limiting recovery to the portions that fit within standard 32-bit limits.