Bug? TC "hangs" with ZIP files bigger than 4GB

MichelPy · Post by *MichelPy » 2004-11-09, 22:47 UTC

I know since long that TC can't create zip files bigger than 2GB

But TC handles existing ZIP files < 4GB very well !
I often have to unzip files from zip files which are between 2 and 4 GB (created with winzip) and TC handles the zip content very well and fast.

But with ZIP files bigger than 4GB (on NTFS) TC "hangs" when opening the zip file (double click on it). the user interface is freezed. I have to kill TC using TaskManager.

I looked at the problem today using Sysinternal FileMonitor.
When TC opens zip files < 4GB it makes some fast read accesses at the beginning and at the end of the file (where the TOC is located). the content is then displayed in TC.

But with zip files bigger than 4GB, TC makes first the same fast read accesses (even at offsets bigger than 4GB), and then TC begins to do a "full read scan" of the zip file from the beginning to the end with 16k chunks. during this reading, TC is "dead" and cannot be reanimated with the ESC or CTRL-break key.

I'm sure TC would work again after some hours and show the content of the zip file...

My question is: why does TC do this "full read scan" when the zip file is bigger than 4GB ?
Is this is a bug ?

If this is a feature, would it be possible to warn the user that opening zip files bigger than 4GB will last between 1 and 10 hours depending on CPU and disk speed

Post by *ghisler(Author) » 2004-11-11, 21:25 UTC

But with ZIP files bigger than 4GB (on NTFS) TC "hangs" when opening the zip file (double click on it). the user interface is freezed. I have to kill TC using TaskManager.

That's strange, I have no problem here with unpacking of zip files > 4GB.

But with zip files bigger than 4GB, TC makes first the same fast read accesses (even at offsets bigger than 4GB), and then TC begins to do a "full read scan" of the zip file from the beginning to the end with 16k chunks. during this reading, TC is "dead" and cannot be reanimated with the ESC or CTRL-break key.

This is an indication that the central directory of the ZIP archive (which is stored at the end) is either damaged, or in a format not understood by TC, so it tries to find out the files by scanning the file. This is done only if the option "open partial zip files" is enabled in configuration - zip packer.

To help me find the problem, I would need the following from you (by e-mail):
1. The last 256k of the zip file (packed inside another zip!)
2. The exact byte size of the zip file

MichelPy · Post by *MichelPy » 2004-11-12, 21:35 UTC

This is done only if the option "open partial zip files" is enabled in configuration - zip packer.

Because I use this option from time to time I redid tests on all the zip files > 4GB I had on my PC at home.
To my surprise

, most of them opened flawlesly

with or without the option "open partial zip files"

.
But I found one zip file still doing the problem

(I will check the files at work next week, I have more of them there)
And on this file the problem happens with or without the option "open partial zip files"

!

To help me find the problem, I would need the following from you (by e-mail):
1. The last 256k of the zip file (packed inside another zip!)
2. The exact byte size of the zip file

I will send you what you asked for by e-mail. This zip file is perhaps corrupt as you think.
But because I experienced this phenomenon more than 10 times in my short life, it is possible that the Winzip versions I used were responsible of creating these "corrupt" files.

Post by *ghisler(Author) » 2004-11-15, 19:48 UTC

Thanks, I will check your file.

MichelPy · Post by *MichelPy » 2004-11-23, 20:38 UTC

I will check your file.

and ...
is it corrupt ?
incompatible ?
who knows ?

Post by *ghisler(Author) » 2004-11-25, 19:53 UTC

I haven't checked it in depth yet, but TC doesn't seem to like the central directory main header. I will try to find out why, if possible before the release of TC 6.50.

MichelPy · Post by *MichelPy » 2005-01-16, 21:39 UTC

I will try to find out why, if possible before the release of TC 6.50.

did you find the time ?
I hate to have to kill TC each time I make the mistake to double-click on a zip file bigger than 4GB (it happens to me now only 2-3 times per month)
If you don't have time, a warning dialog would be helpful, similar to the one when trying to zip something where the result could be bigger than 2GB.
thanks anyway

Post by *ghisler(Author) » 2005-01-17, 19:50 UTC

No, unfortunately not yet, sorry.

MichelPy · Post by *MichelPy » 2005-02-16, 23:48 UTC

Michel Py: did you find the time ?

Ghisler: No, unfortunately not yet, sorry

so if you are short of time, please implement a warning dialog when opening a zip file bigger than 4GB

or let the ESC key stop the zip opening

I now regularly freeze TC when doing file management because of that bug, and I cannot kill TC because the BTM is not finished executing the queued jobs.

And because I cannot save the BTM queue, I have to abort the BTM, kill TC, restart TC and refill the BTM queue...