Problem with ZIP

[Jarmila]

Hello,

I have problem with unpacking files packed via internal ZIP packer inside Total Commander. I backed up e-mail for whole year. I created several ZIP files with size around 735 MB to fit to CD. Than I transfered it to another computer where I have CD burner. But when I tried to open files after transfer, the archive said "archive is corrupted". I tried every "ZIP recovery" software I found at google (like OnTrack, Advanced Archive Recover, Zip recover) but without luck. Problem is that e.g. inside 737 MB ZIP file is only 285 MB of files. The ZIP file have 737 MB size, but unpacked I got only 285 MB. The rest files and folders looks like "not visible" and every "recovery" software recover only that 285 MB no more, no less.

I would like to ask someone if can help, any comment will be great. Thanks in advance

[Sheepdog]

I would like to ask someone if can help, any comment will be great. Thanks in advance

How did you transfer the Data?
Do the original Data still exist?
Do the original Zip-files stille exist on the PC they where backuped from?

sheepdog

[Jarmila]

I transfered data by Network Neighborhood (I think it is NetBIOS or similar protocol). The original data of course does not exist and original zip also not exist.

[Sheepdog]

I transfered data by Network Neighborhood (I think it is NetBIOS or similar protocol). The original data of course does not exist and original zip also not exist.

That is terrible. So there may be the zip damged by transferring via network. The reason could be the network connection or a defective RAM on the source or target PC or anything else. When there are neither the original data nor the original zip you could not even check if the originals were damaged. If you packed the data with TC (as you wrote above) there is a CRC-Check of the zipped files after they are packed by default. That ensures the correct packing of the data.

You can check this setting by opening the wincmd.ini on your source computer and look for the key "VerifyZip=1" if it is set you can be sure that the data was packed successfully. (if it is set to 0 you can't be sure).

Although that would not help in recover your Data.

But there is still the possibility that in your target PC something is wrong while the archives are okay.

Please try to create a zip with similar size in your target PC and with "VeryfyZIP=1" set. When there occurs an CRC Error while packing you should check the hardware on this PC.

sheepdog

[Edit]

Sorry, I mixed the keyname up it is not ZIPVerify but VerifyZIP as I corrected above now.

[/edit]

[Jarmila]

I looked into wincmd.ini, but I din't find what you wrote. With word "ZIP" I have only following:

FirstTimeZIP=0
ZIPLikeDirectory=1
InternalZIP=1
InternalUnZIP=1
zipnt=0
ZIP=pkzip.exe
UnZIP=pkunzip.exe
InternalZipRate=9
Zip83Name=0
ZipSetDateToNewest=0
ZipRecurseSubdirs=1
ZipDirectoryOfFile=1

That's all I have with keyword "zip" inside wincmd.ini Nothing like "verifyzip" or similar as you wrote. I have version 6.53 of Total Commander.

[StickyNomad]

2Jarmila

To disable CRC-Check, you have to enter VerifyZip=0, if this entry is missing or set to 1, the files are CRC-checked (at least on my system, with TCs internal zip).

by default this entry isn't contained in wincmd.ini, so checking should be enabled...

EDIT:
BTW, if I got you right, your whole backuped data is bigger than those ~730 MB and spreaded over more than one zipfile. Did you use any disk-spanning option to span the files over multiple zip-files?

[Jarmila]

No I don't use disk spanning. I manually add files up to 730 MB.

[StickyNomad]

Are all your files damaged that way? (containing less data than it should?)

As you said you created the archives with TCs internal zip, but could by any chance an external Zipper has been used? I ask because e.g. winzip 10 archives may cause compatibility issues when trying to unpack with an incompatible packer.

Just an idea of course,...

[Sheepdog]

As StickyNomad stated: If there is no 'VerifyZip=0' TC performs the CRC check (which is default behavior.)

Have you tried to create a big zip file on your PC? Just in case to see if that fails and the problem is hardware -related? Or just try to re-transfer one 'damaged' zip file and try to verify it on the other Computer (files->test archives').

sheepdog

[Jarmila]

Not all. I created 15 zip zrchives which 10 of them are good. 5 are damaged. Compressed and transfered by same technique. I don't think there is a chance that ZIP files was packed via external ZIP packer (I don't have installed WinZip 10, I have installed only WinRAR).

[Jarmila]

As StickyNomad stated: If there is no 'VerifyZip=0' TC performs the CRC check (which is default behavior.)

Have you tried to create a big zip file on your PC? Just in case to see if that fails and the problem is hardware -related? Or just try to re-transfer one 'damaged' zip file and try to verify it on the other Computer (files->test archives').

sheepdog

I created several times files up to 2GB (because there is a limit using old internal zip packer). I am packing zip files with Windows Commander/Total Commander more than 5 years and I never had a problem like this. This is the first time I had this issue. I think that probably the main problem was the transfer via NetBIOS.

[Sheepdog]

Most problems with damged zips here on the board were hardware related.

RAM is one potential culprit but I remember a ATA-100 cable problem, too.

I'd give it a chance and re-transfer one 'damaged' file to see how it behaves on the source PC. The worst what can happen is that it turns out to be damaged there too. But if not you know htere is still the possibility to recover your data.

sheepdog

[Sam_Zen]

2 Jarmila
I guess you're right about the netbios-connection. ftp could be another option.
A CRC-check is a matter of comparison, so part of that check must be present in the ZIP-file as data.
As soon as this data is damaged, it becomes very difficult to recover the contents.

[sas2000]

 
2Jarmila:

I had a similar problem time ago with a Gigabyte motherboard, it was a nightmare till i noticed that the problem was caused by a bios upgrade (new bios version didn't like my ram).

If you want to be sure that you're copying correctly all your files (until you solve the problem) you may use killcopy v2.82.

 

[Jarmila]

So today I made a test I packed few files into ZIP that was roughly 800 MB big and transfered it via NetBIOS and the file was also corrupted. With FTP transfer the file was good. So I am pretty confused what's going on with NetBIOS.