We have been using ZIPFoundation in our product to create around 5300 compressed archives, and of those about 10 have failed to be decompressed on the server side. While debugging, we found out they also fail to decompress on Windows. The issue is always the same, CRC-32 validation. However, there's no issue decompressing on macOS or iOS, and in that way we could prove that the files themselves are OK.
Moreover, we have a way to force recreating the broken files, and that has succeeded in every case, so the issue seems to be random.
Steps to Reproduce
As you can imagine from the numbers above, this is really hard to reproduce. You just need to create thousand of files until one fails, or take my word for it, as I can't share any of the faulty ones.
Expected Results
Checksum validation should only fail when the zip file is actually corrupted.
Actual Results
In rare cases, checksum validation fails for non-corrupted files.
Regression & Version
We have observed this on 0.9.19, but we have no idea if it's a regression.
Related Link
None, but I wonder if fixing #318 also solves this, as estimating the size may affect the checksum calculation? Sorry if I'm talking nonsense.
I understand that issue only applies to ZIP64 files. Is there a way to force plain old ZIP files? That would also work, here's how we create them:
try FileManager.default.zipItem(
at: /* some URL*/,
to: /* another URL */.appendingPathExtension(for: .zip),
shouldKeepParent: false,
compressionMethod: .deflate,
progress: progress
)
Summary
We have been using ZIPFoundation in our product to create around 5300 compressed archives, and of those about 10 have failed to be decompressed on the server side. While debugging, we found out they also fail to decompress on Windows. The issue is always the same, CRC-32 validation. However, there's no issue decompressing on macOS or iOS, and in that way we could prove that the files themselves are OK.
Moreover, we have a way to force recreating the broken files, and that has succeeded in every case, so the issue seems to be random.
Steps to Reproduce
As you can imagine from the numbers above, this is really hard to reproduce. You just need to create thousand of files until one fails, or take my word for it, as I can't share any of the faulty ones.
Expected Results
Checksum validation should only fail when the zip file is actually corrupted.
Actual Results
In rare cases, checksum validation fails for non-corrupted files.
Regression & Version
We have observed this on 0.9.19, but we have no idea if it's a regression.
Related Link
None, but I wonder if fixing #318 also solves this, as estimating the size may affect the checksum calculation? Sorry if I'm talking nonsense.
I understand that issue only applies to ZIP64 files. Is there a way to force plain old ZIP files? That would also work, here's how we create them: