"Error in packed file ..." (what do I do?)

[Molecule]

I have a sub-gig zip archive, 733 Mb, of important emails, created with TC6.54a.

Double clicking produces the TC message box "Error in packed file ..."

1. What does this mean? Exactly what causes this message?

If the CRC causes the flag, is there a way to have TC reconstruct the CRC, or to have TC unpacker give it a best try, by ignoring the CRC?

A scan of the harddrive (by Norton Disk Doctor, v.5, from NU 2001) finds no errors, e.g. no lost chains, fat problems, etc. The file was created about a year ago, and the hdd is about 3 years old.

(there was a 2003, and a 2004 thread which osculated this question, but given improvements in TC since then, I opened a new thread ...)

(for the Suggestion Box: -- the "Error in packed file" message gives a user the feeling of hanging over an abyss, by the thread of this somewhat dark fact. It would help to add just another sentence to the message box, suggesting what a user might do at this point in time ... an integrated "best-try" archive reconstructor would be nice ... even a few percent would be something ...)

2. Are there any 3rd party tools to be recommended which I might use to try to recover a zip file that has been rejected by TC-packer?

3. Next, am I learning that all zip archives are built on the assumption that hardware failures can never happen. Thus, a failure at any point in the zip file, will effectively exterminate the entire archive? What is the safest archive method for creating multigig archives, with multi-gobs of filenames, which, in the event of a hardware hdd-memory-PSU, etc failure, will maximize potential for partial recovery, in the event of a hardware failure?

4. Is there an archiver (maybe xml?) which just streams the files with no compression, but eliminates slack space on hdds with large FAT clusters?

[sqa_wizard]

You may try the freeware Object FIX ZIP

Caution: Perform repair attempts on a copy of the defect zip file only

Object FIX ZIP will create a new (repaired) file, but who knows ...

[Molecule]

I tried objectfixzip, in w98se with msfn sp2.1.

on loading, objectfixzip opens regedit, which in turn opens a (X) message box "cannot import FileTypes.reg. Error opening the file..." I guess it's trying to register file types, but regedit cannot find the file. After that, the program seems to run.

I think the objectfixzip.exe is an Inno installer ... universal extactor 1.5 (last one to run on 98se) reports an autoit command line error, so I couldn't open the file.

objectfixzip reports "Total 0 files inside archive. Checking data integrity ... Finished." then it pops a (X) message box: "Incomplete zip file."

I tried Zip Repair by Disk Internals. WOW! it worked ... 476 files recovered -- it looks like all of them. Their exe is also minimalist in approach (476k vs. 1.2m for objectfix)

TC team should consider adding a packer repair tool, or a plugin for this tool ... IMHO!

Thus, when TC's zip-unpacker gets snagged by a TOC error or whatever, instead of its "quiting now" message, TC can inform the user in better detail (of the test that caused unpacker to halt), and TC can then ask the user if it should try using this plugin, or its own technology, to rebuild another zip. Where TC unpacker stopped, this amazing Disk Internals Zip Repair opened my "corrupted" zip file toute suite -- in about a minute or so, it zipped up another 733 meg archive (renamed), which, from what I can see, now includes all the original files in the "corrupted" zip. TC unpacker now opens the new zip just fine!!!

AWESOME: http://www.diskinternals.com/zip-repair/

[sqa_wizard]

Thanks for reporting your results here !

Diskinternals one was my 2nd choice, because I already had success with ObjectFix ...

I will consider ZipRepair now as an alternative.

[Molecule]

thanks to you, sga_wizard.

I feel more confident again, about using TC zip files again.

Whatever it was that gave TC reason to quit trying, disk internals apparently saw as irrelevant. It created a repaired zip file in about a minute -- roughly the same amount of time it took TC to create the original.

I don't know what compression method was used to create the restored archive, but the original packer zip is 733,378,207 bytes, and the repair zip is 733,368,321 bytes -- almost exactly 10k smaller. Maybe a virus???

I plead with GH to investigate use of this technology -- so that when TC tries to open one of its own zip files and usual methods fail for some specific reason, that TC doesn't just in effect quit. It's frightening to double-click a TC archive, and have TC say nothing more than "error in archive." Maybe TC could offer a user the possibility of using this technology to repack the file.

[sqa_wizard]

Maybe a virus???

This could be possible indeed.
May a virusscanner has removed a bad attachment of an email a while ago, without repacking it correctly (adapt the CRC accordingly).

[ghisler(Author)]

Could you use Files - Compare by content with the bad and fixed zip, please? I wonder what is really different, e.g. are there missing parts, or just a few bytes changed?

Btw, TC can fix a damaged zip if the central directory at the end is completely missing, it then reads the files one by one from the beginning of the file. I guess that the central directory is there, but damaged.

[Molecule]

I remember a dos FC utility, but can't find it. the 733 meg files are too much for my 512 meg machine -- file compare by content produces "not enough memory - the files are different"

I'd like to help on this, as I am dependent on TC and zip. I always let TC verify, and I verify the archive myself, before I delete any files.

I don't think it was virus (adding or removal). My hunch is it was probably a voltage drop in my then overloaded UPS-PSU power supply system, which after I added a 4th hdd gave me a few months of a variety of vague echelon-virus-poltergeist like problems, with memory, etc. NDD identifies exactly which files have fat-file & defrag problems, but it never indicated a FAT problem on my data partitions.

What impressed me was how easily it was repaired. One screen and two clicks (to identify the files). done. TC would already know the file name when the double-click fails.

Give me a day or two ... I'll do a compare on a larger machine. I want to know myself.

[ts4242]

the 733 meg files are too much for my 512 meg machine -- file compare by content produces "not enough memory - the files are different"

You can split the two files into two different folder then synchronize these folders, you must split using the same size e.g. 100MB