Support

Did you read the documentation? There's an "About the ZIP file format and its compatibility with third party software" section which should answer your questions.

The TL;DR is that it's a side-effect of us using archive spanning and avoiding the calculation of CRC32 checksums for files over 1MB to prevent the backup from failing. It is a purely cosmetic issue on extraction, though. I know for a fact that 7-Zip extracts the archive fine, despite telling you there's a CRC error.

As to whether it can be avoided. Not right now, and even if I did something about it, it would only be a partial success. I could always give you the option to calculate CRC32 checksums for large files; PHP's hash_file is relatively fast on most servers. As long as you don't have files which are several dozens of Megabytes big it would work. However, most third party ZIP unarchivers use the InfoZIP library which is NOT spec-compliant for multipart ZIP archives. This is a standing bug in InfoZIP since its inception 37 years ago. It does not follow PKWARE's APPNOTE.txt (the ZIP specification) when it comes to spanned archives – that's what multipart archives are officially called in the spec. Since our archives are always created as spanned archives, InfoZIP cannot read that header and complains about the integrity of the archive even though the archive we produce is spec-compliant.

There's a reason I created the JPA archive format, Kickstart to extract it on the web, and Extract to extract it on your desktop.

The link I gave you takes you directly to the ZIP archiver documentation which has the "About the ZIP file format and its compatibility with third party software" section. I mean, I think it makes sense a question about ZIP archives is answered in the documentation section talking about ZIP archives. Right? Genuine question. I am trying to make the documentation organized in logical manner :)