|
|
Post by Nick on Feb 2, 2005 16:19:30 GMT -5
Using 3.05 Build 1 (just purchased so no experience with previous versions) with Delphi 5.
My application does a lot of zip/unzip for movement of files between users in a networked environment. I am porting away from another zip tool. I am getting situation where VCLZip on one machine is creating bad zip files. That same machine is able to read the bad zip file it created ok but no others can (nor can winzip).
When I use different machines to create the same zip file using VCLZip in my application (using common data files), I get a "good.zip" and a "bad.zip".
Examining the "bad.zip" shows the local file header signatures to all be 0x00000000. The file lengths between "good" and "bad" are the same, file names in the headers look ok, the actual compressed data looks like it may be different.
Nick
|
|
|
|
Post by Kevin on Feb 2, 2005 20:38:17 GMT -5
This is a new one.  Can you see any pattern as to what machines are producing the bad files? It really doesn't make sense that the same machine that created the bad zip can read it, but, that should hopefully be a clue. I'm just not sure yet what to make of the clue.  Kevin |
|
|
|
Post by Nick on Feb 2, 2005 23:26:00 GMT -5
It's one of those things where everything worked fine, and then all of a sudden it was pushing out bad zips. I was equally amazed to see that it could pull the bad zips in again (since other machines running the same code could not).
Is there any way the header signature can be generated with zeros? Or ignored on input? Or is sensitive to some other unrelated machine condition?
After I generate a zip file (VCLZip.Zip), all the while checking for errors and exceptions, I always run VCLZip.CheckArchive on the file that was just created (again checking for errors and exceptions) so that I know things are good. The same mechanism that lets the software read the "bad" file back in must have also not have seen any problem with the file.
I have a copy of a "good" and "bad" zip if that can help.
Nick
|
|
|
|
Post by Kevin on Feb 3, 2005 10:43:47 GMT -5
I don't know of a way off hand that it would be generated with all zeros. Is it just the signature that is zero's?
Can't hurt to send me the sample zip files you have.
Thanks,
Kevin
|
|
|
|
Post by Nick on Feb 3, 2005 11:37:34 GMT -5
I needed to recover some of the bad zip files so I tested my theory.  In module "kpZipObj" procedure "setZipSignatures" I set all of the variables to zero (CENTSIG, LOCSIG, ENDSIG, ZIP64EOC, ZIP64EOCL, LOC4, LOCSIG, LOC3, LOC2, LOC1, END4). I was then able to read the bad zip files, change the code back, and recover them.  My current working theory is that since these variables are only set once when the module loads during initialization, that if they were corrupted (pointers? overflowed buffers?) during the programs execution, they would remain corrupted until the software unloads. During this time, it would think the zip files it had created were valid and still be able to read them because those are the same constant values it had used to create the zip files. Somehow I suspect I'm going to have to be the one to try and trap when the error actually occurs during execution. Any hints on pieces of code that tries to zero out or write to buffers with pointers? I'm using Delphi 5. |
|
|
|
Post by Kevin on Feb 3, 2005 18:27:42 GMT -5
I'll have to poke around and see if I can tell where that could be happening.
The interesting thing is that you say this only happens on certain machines? Any pattern you can notice as to what machines? Similar OS, or anything like that?
Kevin
|
|
|
|
Post by Nick on Feb 11, 2005 2:21:21 GMT -5
I'll be tracking this down (soon I hope).
But, is there a reason those variables are global and set with "setZipSignatures" during module initialization instead of either being constants or put in TVCLUnZip and called when the class initializes?
|
|
|
|
Post by Kevin on Feb 14, 2005 9:33:48 GMT -5
Offhand I don't remember what the reason was, but I remember there being a reason. It's just been so long since I wrote that part.  I'll take a look tonight and see if I can remember why I did it that way. Kevin |
|
|
|
Post by Nick on Feb 24, 2005 9:38:39 GMT -5
After attempting break points, traps, adding some code to double check, rebuilding my projects, etc., this error has not reoccurred. Since I use a fair number of packages, at this point I think it might have been some sort of issue with mismatched interfaces during my switch over.
Still, out of paranoia I removed the initialization section in kpZipObj by converting the signatures from variables to constants.
Thanks
|
|
