archive
archive copied to clipboard
brendan-duncan
Reading a corrupted zip file with no EoCD results in a really long loop while trying to find signature
At the moment _findSignature(InputStream input) doesn't have a limit on how deep from the end it should search for End of Central Directory. So when a corrupted zip file is passed with a missing EoCD it very slowly iterates through the whole file halting any other execution (a 15mb file takes few minutes on android emulator). So if a user has a corrupted file mixed in with normal files and is batch unpacking, it will freeze the execution with no indication of what is happening. Checking of crc is also not an option if EoCD is missing.
An option would be limiting the depth. On wiki it is said that the EoCD section should not be bigger then ~64kb, though no such info in the zip specifications.
Another option would be a faster search algorithm after the first 64kb with some buffering.
Zip extractors on PC give out an error almost instantly. Attaching a corrupt zip file for a test.
I'll see if I can do anything to improve that performance. Certainly PC extractors will have significant advantage there, they can get away with a lot of things Dart can't, but it can certainly be improved. The size of the EOCD isn't the issue, it's that they put it at the end of the file, meaning you have to search backwards, and there's nothing to say there can't be any amount of other data after the EoCD, meaning you can't just read the last 64kb. So the theoretical worse case is it has to read the entire file backwards, which is what's happening.
Hi there. I'm also facing a similar issue. Even when reading small corrupted files (5 MB) from a network storage, it takes minutes in this mode. Initially, I thought the isolate had frozen, but then when I looked into the code, I found this loop. I'd love to hear if there've been any updates regarding this issue.
Update - Found a bug with duplicate checks in _findSignature #351. This improves reading time. Please have a look.
