7-Zip reports Headers Error

[kolesar-andras]

Recent versions of 7-Zip report an error for any zip file created with ArchiveStream.

$ 7z t example.zip 

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=hu_HU.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs Intel(R) Xeon(R) CPU           E5640  @ 2.67GHz (206C2),ASM)

Scanning the drive for archives:
1 file, 936 bytes (1 KiB)

Testing archive: example.zip

ERRORS:
Headers Error


WARNINGS:
Headers Error

--
Path = example.zip
Type = zip
ERRORS:
Headers Error
WARNINGS:
Headers Error
Physical Size = 936
64-bit = +

    

Archives with Errors: 1

Warnings: 1

Open Errors: 1

example.zip was created using the following code:

<?php

require_once('src/Archive.php');
require_once('src/ZipArchive.php');

use Barracuda\ArchiveStream\ZipArchive;

$zip = new ZipArchive('example.zip');
$zip->add_file_from_path('LICENSE', 'LICENSE');
$zip->finish();

PHP output was simply redirected to ZIP file:

php example.php > example.zip

Older 7-Zip versions (for example 9.20) do not report any problems about the same file:

$ 7z t example.zip 

7-Zip 9.20  Copyright (c) 1999-2010 Igor Pavlov  2010-11-18
p7zip Version 9.20 (locale=hu_HU.UTF-8,Utf16=on,HugeFiles=on,2 CPUs)

Processing archive: example.zip

Testing     LICENSE

Everything is Ok

Size:       1144
Compressed: 938

Most of out clients use Windows. Some of them reported difficulties to extract our ZIP files. Recommended them to use 7-Zip, downloaded recent version (18.01) tested a file, got Headers Error.

[kolesar-andras]

These two commits fix issue mentioned above. Both mentioned versions (16.02 and 18.01) of 7-Zip report OK. Output of 16.02 on Debian:

$ 7z t example.zip 

7-Zip [64] 16.02 : Copyright (c) 1999-2016 Igor Pavlov : 2016-05-21
p7zip Version 16.02 (locale=hu_HU.UTF-8,Utf16=on,HugeFiles=on,64 bits,2 CPUs Intel(R) Xeon(R) CPU           E5640  @ 2.67GHz (206C2),ASM)

Scanning the drive for archives:
1 file, 938 bytes (1 KiB)

Testing archive: example.zip
--
Path = example.zip
Type = zip
Physical Size = 938
64-bit = +

Everything is Ok

Size:       1144
Compressed: 938

[PowerWeb5]

I've encountered similar issues with .zip files created via Windows (eg. (Send to > Compressed (zipped) folder" in File Explorer) resulting in vague "Headers Error" errors and unzipping to 0-byte file as well as "Warning: There are some data after the end of the payload data" (which does at least unzip correctly) for all versions of 7-zip (from recent v18.06 back to v9.20 in 2010, both 64-bit and 32-bit via GUI and command line). Even verbose command line options and Test archive fail to provide any further details.
However, I've identified the root cause at least for "Headers Error" in many cases being mismatch with File Size and/or CRC file metadata vs. the resulting unzipped file size and/or CRC, in cases I've seen so far.
You might be encountering similar issues or root cause of them. It's possible this might occur more often if files are open or still being written to when being zipped via Windows at least, and possibly with your own utility.

As WinRAR, Windows Extract and other utilities handle these zips just fine, despite mismatched CRC and/or file size, 7-Zip should do the same, instead of producing needlessly corrupted 0-byte files as it does now (with Headers Error), and should therefore also be consistent with cases where file is at the end of the archive, instead of showing a "Data after payload" warning while still correctly extracting the non-zero-sized file as is the case now.

Strangely, other utilities such as WinRAR and Windows Extract unzip just fine and even perform Test archive without reporting anything, despite showing the same mismatched when using WinRAR to inspect the file properties, when at least WinRAR should be at least showing a warning message in such cases.

I've reported this bug to 7-Zip here, where I've also referenced your issue report here as one of a number of examples of 7-zip failing to handle this correctly like other zip utilities.

If you also believe that 7-Zip should fix this inconsistency and be able to correctly unzip such .zip files (albeit with a warning) without needlessly producing a corrupted 0-byte file instead for some of the files in those archives, then I'd welcome your input and thoughts on the priority of this via comments on my bug report on SourceForge for 7-Zip.

[GuyPaddock]

Something else to try, if the ZIP file is > 4 GB and was created by OneDrive or Windows, is a utility designed to fix-up the headers:
https://github.com/pmqs/Fix-OneDrive-Zip

Apparently, there's some disagreement about how to handle the "file count" header for Zip64 files. Microsoft products expect that the file count header should be 0 while other systems expect it to be 1. Newer versions of 7-zip for Windows (versions 19+) handle the issue fine but Linux only has an older POSIX port, p7zip, that is version 16 from 2016, and it does not have a way to handle this issue.

If you're curious, someone did a deep-dive on the issue here:
https://www.bitsgalore.org/2020/03/11/does-microsoft-onedrive-export-large-ZIP-files-that-are-corrupt

[101arrowz]

Came across this issue in fflate and wanted to report that the cause of the issue in my case was the STREAMED flag in the general purpose bitflag being set in the local headers but not the central directory. See my comment for more details.

This might also be happening here. The genb parameter (general purpose bit flag) looks like it's 0 by default in the central directory but it should be 8. If #45 actually fixes the issue of course I'm just wrong but it's interesting to investigate.