Problem with zip64 on native Xiaomi archiver utility #18
Comments
|
Please confirm if the mod_zip generated files are actually in zip64 format. From a quick look at the code, mod_zip only uses zip64 if the file size is > 4GB. If you have zip64 file encoded using the data descriptor method (stream) that works in Xiaomi, please upload it here, then it would be easier to debug the issue. |
|
Yes, we are talking about 4Gb+ files that mod_zip streams as zip64. I've attached smaller files just as an example, because the problem is reproducible with them both with the native Xiaomi-phones archiver utility and with |
|
I meant, I want a file that works in Xiaomi, I am assuming the above one is not working in Xiaomi? |
|
Sorry for the confusion. All Broken
|
I want a zip64 file (with data descriptor encoding) that works on Xiaomi. The test.zip is non zip64 file generated by zstream. |
|
I built the mod_zip locally and modified it to use zip64 for all file sizes. Since it knows the file size, it is setting the correct size in the local header itself This is not possible in zstream case, as it works on stream abstraction and doesn't know the file size. Full output below |
|
Here are some more examples: Working file from Broken file with the same content from Is there a way to extend |
|
could you check if any of the following variation works?
if crc and size available, this is possible, but might require a bit of work on zstream side |
|
None of the three work on Xiaomi :\
|
|
We have the CRC and the size for all files. It would be fantastic to support this case! |
|
if CRC and file size are available, and the coder is Zstream.Coder.Stored, then yes, it should be possible to drop the data descriptor and put all the details in the local header itself. I will see if I can get something out this weekend |
|
Thanks a lot! Looking forward to it. Please let me know if I can help with anything. |
|
could you try #19 |
|
Archives > 4Gb are still broken on Xiaomi 😢
Here is a test archive https://take.ms/Z58ua |
|
@dmkl I have pushed some changes which seem to remove the warnings messages I used to get on zipdetails. Can you give it another try. If it doesn't work, I need to find a way to run Xiaomi or something equivalent so I can test it. |
|
Thanks for another attempt! It didn't fix the issue, unfortunatelly 😕 All is the same. Here is a test archive. Please let me know if I can help with any other tests or info. |
I checked this file, you can find the zipdetails output below. This is not a zip64 file. My guess is, Xiaomi doesn't support zip64 at all? As per zip spec, zip64 is really needed if size/offset used in the file exceeds the 32 bit range. I am guessing, in this case individual file size didn't exceed 32 bit range and mod_zip decided to not use zip64. Anyways, We need to verify if Xioami archive utility supports zip64 at all. Also, is this something I can download? I have android phone and can check it, but can't figure out how to get the utility. Google search doesn't return anything useful. |
|
I've done another test.
The fact that Xiaomi can handle mac's archive makes me think that it supports zip64. Wdyt? |
|
Interesting, could you share the |
|
|
|
Hi Anantha, do you have any further ideas on this topic? |
|
I haven't looked at the issue since my last comment. I have been working on a few other things. The main issue is, I don't know how much time would be needed to figure out the root cause. I also don't have a way to reproduce it locally (and verify the fix), which makes it very time-consuming. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We are streaming lots of archives with
zstream. It works very well except the native Xiaomi archiver utility, that fails to unzip azip64archive. The first idea was that this is a bug in that utility, but it handleszip64archives from another streaming solution mod_zip with no issues.Another hint that something might be wrong with
zip64format is thatzipdetailsmac/linux util fails to displayzstreams zip64 details. Here is an example script and files.10.txt
test.zip
test_zip64.zip
The text was updated successfully, but these errors were encountered: