Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

PKUNZIP in Command Window of XP 2

Status
Not open for further replies.

WBSimpson

Programmer
Oct 19, 2001
8
0
0
US
PKUNZIP 2.04G running in the command window of XP is beginning to show a new problem for us at the state of NC. I don't know if XP has anything to do with it, but Seat Management here keeps pushing software and updates on to our PC's, so can anyone guess why PKUNZIP suddenly became a problem? We have used PKUNZIP (and PKZIP) for years, but in the last month it began to show this new behavior.

In one example, PKUNZIP consistently reports CRC errors on 4 out of 49 files. FoxPro calls the PKUNZIP.EXE, but the same error occurs even if PKUNZIP is executed singularly in the XP command window.

Other clients are beginning to submit their ZIPPED files on diskette and some (not all) of these are unzipping with similar CRC errors.

It doesn't seem to be the PKZIPed files fault exactly. We can unzip and rezip the files using WinZip (a 32bit app) and the problem goes away, which tells me the complete data are in the original PKZIPed files!

I know, everyone has probably already moved all their apps from the DOS world, but please, has anyone had a similar problem? PKWARE and their tech support have moved on, and they are unable to help.

The last 16bit (2.50 ) version of PKUNZIP has the same CRC problem when extracting the test sample.


I tried pausing between files during extraction, but that makes no difference.

I've looked for a different DOS zip utility replacement, but PKWARE seems to make the only one capable archiving across multiple diskettes. The UNZIP utility created by InfoZIP doesn't produce the CRC error (on the sample file at least) but cannot create multiple diskette ZIP archives.

We distribute PKunzip as a component of an application written in FoxPro 2.5 for DOS, which will be very expensive to the state of NC to rewrite as a 32bit app. I hope someone knows what is going wrong or can suggest a solution or an automated workaround.

I could send the sample file if someone wants to take a look at the problem.
 
Winzip has a command line client available that should fix the issue if their unzip utility works on these files. You should be able to just rename the executable and push it to the clients.

Good luck with this. These are the types of problems that can cause IT pros to think about changing professions!
 
WinZip is excellent good but a licensed product.

For a freeware (GPL) version, try 7-Zip. It works well under XP and includes a commandline version (see
Unfortunately, it's not immediately clear whether it supports spanning floppy disk and I haven't had time to check.

Hope this helps...
 
A CRC error is an error reading the file. If you're only using one PC to read the disks it could be that the floppy drive on that PC is on the way out.

Regards

Nelviticus
 
We can unzip and rezip the files using WinZip (a 32bit app) and the problem goes away, which tells me the complete data are in the original PKZIPed files!

Wouldn't that mean that WinZip should be unable to read the file?
 
Rick998,
I just checked 7zip and it doesn't span disks. As a state gov, we can't require the public to use larger media than the common diskette, so PKZIP and PKUNZIP have served quite well by spanning (until now).

Also, it does seem reasonable that WinZIP would have problems, but that's just not the case.

While searching the 7zip forum, I found a comment saying that some zip software creates two headers in the archive, and some unzip software doesn't read beyond the first header. This could be the mechanism? Perhaps a corrupt 2nd header in a zip file that WinZIP skips? If that's the case, then the problem would be that PKZIP can create a bad 2nd header, (which assumes that PKZIP creates two headers in the first place).

CYoung,
I'm going over to WinZIP site and find out if WinZip spans, and see if the dual header might be an explanation. I'll report back what I find if anyone is interested.
Thanks all!
 
i have used pkzip 2.04 on the xp command line (ntfs) with no problems in the past. have you tried copying the spanned zips to folders on the hard drive just to see if the crc errors are gnerated on the first of the spanned set? also, are you using ntfs or fat as a filesystem?

and, how are you invoking the command prompt? are you using "cmd" or "command?"

lastly, you havent deployed or upgraded to a new antivirus lately, have you? im wondering if an on-access scanner might be interfering with pkzip...

 
Hi jimp56,
I haven't had problems until recently, either. And it's only been two clients submitting cost reports that can't be completely unzipped.

Foxpro "runs" pkzip and pkunzip in Window's Command Window, or if a client still has a DOS based system, then in DOS. I don't think there are many still using DOS or 16b Windows sysyems anymore.

Is there a difference between CMD and COMMAND? I thought there was just the "Command Window" which emulates DOS functionality in XP.

Hi cyoung,
I looked into WinZIP's command line client. It correctly unzips the problemmatic zip file, but must be installed on a licensed WinZIP machine. If you copy the files to a non-licensed PC, it tells you and quits. Maybe we can get some special enterprise license from WinZIP, but man, I would have to know that it would reliably work in all cases before recommending that.

These two cost reports were submitted on individual diskettes, not spanned. Spanning is just a requirement since we never know if a client will create a report needing more than 1.44 Mb.

There may be something to the AV comment. Has anyone experienced an AV issue with pkzip?

Hi Rick998,
I'm going to look into Zipgenius again. I thought it was windows only but I'm going back to check that out.

One of my problems is that I can't duplicate what the clients have done, namely creating bad zip files. I've got one of their bad zips, but I can't say how it was created. I do know that, when extracting it in WinZIP's commandline client, it displays the following error message:

Warning: the size of the extracted file (10839) does not match the uncompressed size (7905) recorded in the zip file

This is the same warning (with different numbers of course) that displays for each of four other files out of 49. The files are not bad, but can be opened as good foxpro tables fully intact. (PKUNZIP displays CRC errors for these 4 files and the files cannot be opened after extraction).

Thanks for all the help, everyone. I'm not giving up, but the list of possibilities seems to be shrinking!
 
Floppy disks are not the most reliable of media, so your bad zip files could be bad because they were saved on unreliable disks, rather than through any fault of your clients.

I'm no expert on Windows' filing system but it's entirely possible that PKUNZIP - a DOS program runnning in an emulated DOS environment - interacts with the disk's filing slightly differently than a Windows-based program like WinZip. Thus it's possible that PKUNZIP could fail to correctly read a file that WinZip successfully reads. Maybe native file access under Windows has better error-handling than emulated file access under DOS.

If you copy the zip file from the disk to your hard drive using Windows Explorer, then use PKUNZIP on the hard drive version, do you still get errors?

I like the idea about your anti-virus scanner though. See if there's an option to disable on-access scanning for the floppy drive, or on-access scanning of zip files. If you're worried about viruses just make sure that the the floppy is scanned before you run it through FoxPro.

Regards

Nelviticus
 
Hi Nelviticus,
PKUNZIP has the same problem if I put the file on the C: drive (same crc errors). We now have identified more than 30 "bad" zip files out of over 360 received from the field.

It seems that a difference between PKUNZIP and the Command version of WinZIP is that winzip simply warns that the uncompressed file size does not match size recorded in the file header. Each zipped file has a header for each compressed file, and for some files, these sizes don't match up. So now I see it as a PKZIP problem where some of the file headers are written incorrectly during zip process. Our experience shows that this has occurred in less than 10% of the zip files submitted.

As WinZIP extracts, it displays a warning message for each of the "bad" files, but unlike PKUNZIP it extracts the file anyhow. So we are getting around the problem by using the command version of WinZIP's WZUNZIP in a .BAT file to test and process files before uploading them.

I would really like to thank everyone who offered help and advice. I guess we're going to use the WinZIP two-step workaround for now, but I'm gonna keep thinking about it...
 
We never found an explanation or fix for this CRC problem. A different PKware problem has surfaced, so it seems to belong in this thread.

We are using Win XP and pkzip/pkunzip in the command window to create spanned sets of diskettes (file data too large for one disk). When we try to pkunzip the spanned set, XP dies with a Blue Screen of Death and stop code 8E. Here are the steps to duplicate the problem:
(1) put in first disk (of 4 in this case) and type:
pkunzip a:\*.*
(2) It asks for last disk. Put in last disk (no. 4)
(3) It then asks for 1st disk again.
(4) Put in 1st disk and [enter]. BSOD results.

We've repeated this on a number of PC's, all under seat management control. This problem didn't exist until something was updated or installed, probably in mid December. I don't know what it was, but our S/M is looking into the issue now.
I can't figure out why we in state government (NC) seem to be the only group having this problem, or at least talking about it. My Google searches come back empty for this. Has anyone else had similar experience?
 
Hi,
What XP version ?



[profile]

To Paraphrase:"The Help you get is proportional to the Help you give.."
 
an alternative would be to pkunzip the data in a 98 machine and then unload it to an xp machine using lan.
 
Just a thought but... are your Win XP PC's configured for Automatic Update (i.e. Windows Critical Updates)?

The reason I ask is because Microsoft's monthly release of Critical Updates ('Patch Tuesday', i.e. the second Tuesday of each month) fell on Dec 13th 2005.

Could this have been the reason why the 'problem didn't exist until something was updated or installed, probably in mid December.'?

To check, have you tried un-installing December's Critical Updates (or used a System Restore point - if configured - before Dec 13th)?

Hope this helps...
 
The version is 5.1 SP1, XP Pro.

These PC's are not configured for auto update as far as I know, but are updated as necessary thru our Seat Management vendor (ACS).

Patch Tuesday might coincide with the change in our status. I'll mention that to our contacts here.

As users we can't install or update anything. I was just hoping to find others that have had the same experience and could pass along some information that I could forward to our S/M folks.
 
WBSimpson,

It sounds very much like you have a 'totally managed desktop', (probably) outsourced to 'Seat Management vendor (ACS)'.

If so then I'm sorry but your scenario is outside of my day-to-day experience and complicates any possible advice I am able to provide.

In view of your very first post ('Seat Management here keeps pushing software and updates on to our PC's'), have you raised this issue with 'Seat Management'?

Regards,
 
Yes, Seat Management has had this item for a while. It seems that either:
(a) people like us still using aged DOS apps deserve (and get) little attention, or
(b) we are unique and the only ones anywhere having this problem.

(B) seems probable since there is so much "stuff" pushed regularly onto our "managed" desktops.

Thanks to all for all your kind efforts. I'll keep visiting the forum and maybe someday I'll be able to offer something useful.
 
I found out one thing about PKUNZIP, spanned disk sets, and XP's BSD problem. This could be useful to anyone having the same problem I'm having. If I put PKUNZIP.EXE on the last of the spanned disk set and invoke it there:
cmd.exe
A:>
PKUNZIP *.* C:\targetpath

Then it works! But if I try to invoke PKUNZIP from the C: drive, it always produces a BSD with Stop code 8E after the 2nd disk exchange.


 
Hi.
A bit late but if you are still interested.
You could try not putting in the lst disk ( the second time) but hit enter , the system realizes no disk , complains, you put it in and now it really does read the 1st disk, not just remember what was on the prev disk and say that it is wrong. This problem occurred on a number of 98 systems for cd and floppies and sometimes on xp at least for cd where nero etc was helping out.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top