- Wine cannot be extracred by the unarchiver zip file#
- Wine cannot be extracred by the unarchiver archive#
- Wine cannot be extracred by the unarchiver zip#
Wine cannot be extracred by the unarchiver archive#
It might also be quite likely that I will not come up with a workaround fix for this in zip4j, as the real cause of issue is with Mac's archive utility. I will spend some thoughts on this issue and think about the implications of the above workarounds. This is definitely not an issue with zip4j, but rather is an issue/limitation with Archive utility.
Wine cannot be extracred by the unarchiver zip#
Depending on the size of the zip file, this might be an expensive and time consuming operation. Remove the first 4 bytes of the generated zip file, but this would mean rewriting the complete file again. You can argue that such a file can anyway not be extracted with streams, as this has split zip header as the first 4 bytes, but having split zip header as first 4 bytes probably makes more sense than having 0's.
Wine cannot be extracred by the unarchiver zip file#
The biggest downside of this workaround would be that the zip file will not work with Streams (ZipInputStream), as they expect the first 4 bytes to be the central directory signature. I tried replacing these bytes with 0's and the Archive utility was able to successfully extract this. Replace the first 4 bytes to something other than the split header signature. There are a couple of workarounds for this: The headers there have much more clear information if the zip file is actually a split zip file or not. The right way for any tool to check for a split zip file is to check the headers in the end of central directory record, and not just the first 4 bytes of the zip file. For this reason, it is totally valid to have the first 4 bytes as a split header for a non-split zip file. By the time we know this information, we have already written the 4 byte split zip header. And since the first 4 bytes have to be written before the start of compression, it will be hard to predict upfront if the final size will be less than the split size or not. If you are adding a 200kb file to a zip and set the split size to 100kb, it might seem that there should be 2 parts to it, but after compression, depending on the file, the compressed size, and the total size of the zip, might end up being less than 100kb.
The reason is that, it is hard to predict upfront wether a zip file will end up being a split zip file or not. But it is totally valid to have such a header even for non-split zip files.
Now it might sound reasonable that Mac's Archive utility fails in this case, as it found a split zip header for a non-split zip file.
This ends up in a situation where a zip file has the first 4 bytes as split zip header, but in fact, the zip file is not a split zip file, and has only one part (because of the reason mentioned above), and since Mac's Archive utility does not support split zip files, it throws an error. In this case, these 4 bytes end up being the split zip header. According to the zip specification, a split zip file has to have a 4 byte split zip header as the first 4 bytes of the first part of the zip file. For example, if the createSplitZipFile() method was called with a split size of 100kb and the total size of the zip file ends up being only 60kb, then there will be only one zip file (filename.zip) instead of (filename.z01, filename.z02. In this case, a zip file was created with ZipFile.createSplitZipFile() method, and the generated zip file ended up being only one part because the total size of the zip file was less than the split size passed in the method argument. You can also skip to the last paragraph for a conclusion/summary of this issue. This will go into the details of the issue, which might not be interesting for everyone, but this will be a reference for me for the future or for anyone else facing similar issues. Read on for more technical details of this issue. This is a limitation of the Mac's Archive utility.
0 kommentar(er)
