I've noticed that the FILE_ID.DIZ files in the following archives are
messed up.

inter50a.zip
inter50b.zip
inter50c.zip
inter50d.zip
inter50e.zip
inter50f.zip

These files are Ralph Browns Interrupt List. When I use pkz204g to open
the first file, some of the lines in FILE_ID.DIZ are askew. The rest of
the archives just give garbage when the FILE_ID.DIZ files are being
un-archived. Does anyone else notice that?

In article <4pkdn0$4...@trumpet.aix.calpoly.edu> prock...@trumpet.aix.calpoly.edu (Patrick D Rockwell) writes:

I haven't noticed anything wrong.  If the problem is only with the
FILE_ID.DIZ files, it shouldn't be any big deal since they're just for
record keeping.

In article <sinykal.390.00170...@{*word*104}space.org>,

In article <4pm3io$...@newton.cc.rl.ac.uk>,
Richard Cullen  <I...@SIRIUS.TN.RL.AC.UK> wrote:

prock...@trumpet.aix.calpoly.edu (Patrick D Rockwell) wrote:

Don't understand...   :-/
Richard  

In article <4pm3io$...@newton.cc.rl.ac.uk>,
Richard Cullen  <I...@SIRIUS.TN.RL.AC.UK> wrote:
:I found a problem since I was FTPing using Netscape 1.1. I found the files were
:corrupted, so I downloaded them a second time and they were fine.
:
:Don't understand...   :-/

This is a common problem with Netscape. When you get corrupt zipped
files when downloading with Netscape, you should exit Netscape, load
it anew and then get the file. I do not know the reason, but I have
had the same problem with version 1.22. This is the remedy.

   All the best, Timo

In article <4pljqo$1...@trumpet.aix.calpoly.edu>,
Patrick D Rockwell <prock...@trumpet.aix.calpoly.edu> wrote:
:Yes, I did. They tested normal, but I still get the garbage.  I got them
:from ftp.hk.super.net/.4/programming/docs/
:Maybe I should've gotten them from the same place that you did.

The reason just might be in here:

An edited extract from

Archive-name: msdos-archives/faq
Garbo-archive-name: ftp://garbo.uwasa.fi/pc/pd2/camfaq.zip

                                        Copyright (c) 1993-1996 Timo Salmi
                                                       All rights reserved

Frequently Asked Questions of the Usenet newsgroups
comp.archives.msdos.announce and comp.archives.msdos.d
======================================================

6. *****
 Q: Something is wrong with the .zip (.zoo) etc package I downloaded:
    I get a CRC error, a "requires PKUNZIP 3.0 or higher version", a
    "zipfile is part of multi-disk archive" message, or whatever when
    I try to process the .zip package I downloaded from an MS-DOS FTP
    site.

 A1: 1) Use a binary transfers at all phases. (Both from the FTP
        site to your host and from your host to your PC.)
     2) Use a version 2.04G compatible extractor on your MS-DOS PC:
         "ftp://garbo.uwasa.fi/pc/arcers/unz520x.exe"
         "ftp://garbo.uwasa.fi/pc/arcers/pkz204g.exe"
     3) PKZIP 2.04G compatible Unix (actually multi-platform) version
        by the Info-ZIP programming group is available as
         "ftp://garbo.uwasa.fi/unix/arcers/unzip512.tar.Z"
         "ftp://garbo.uwasa.fi/unix/arcers/unzip52.zip"
         "ftp://garbo.uwasa.fi/unix/arcers/unzmake.inf"
        Using the old Unix version for testing 2.04G .zip files on
        Unix can cause false CRC error messages.

 A2: In over 99.9% of cases the allegedly corrupt packages are
caused either by the user's failure to transfer the .zip packages in
the binary mode or using an outdated version of PKUNZIP.
In file transfers there are (usually) two phases:
 A) From the FTP site to your host.
 B) From your host to your PC.
 Failure the transfer in the binary mode can cause quite unexpected
error messages like for example "requires PKUNZIP 2.8 or higher
version".
   It is fairly common of the users to claim that they have
transferred in the binary mode, but in fact done so for only one of
the stages! Usually you transfer the zipped file in two stages.
First from the FTP site to your own (most often Unix) host. That
transfer must be made in the binary mode. Second from your host to
your PC. Also this second transfer must be made in the binary mode.
In particular, if you are using the kermit protocol for the
transfer, you must set the transfer to binary mode at _both_ ends of
the transfer.
   Failing to set the transfer to the binary mode, and using the old
versions of PKUNZIP has caused innumerable false alarms from the
downloaders to the FTP archive site maintainers. It is not
impossible, but it is extremely rare that a package is actually
corrupt on the FTP archive site.
   In some very unusual cases setting the transfer to binary is not
enough because the byte order of your host and the FTP site might
not be the same. That is why most ftp programs have a mode called
TENEX, which tells each end to use binary mode but to sort out the
byte ordering differences between the two machines. If your ftp
program does not have the TENEX command you can make it do the same
thing by issuing these two commands:
 ftp> binary
 ftp> quote "TYPE L 8"
The double quotes are required.
   Some users with .zip problems want to know where to get PKZIPFIX.
It is within the PKZIP distribution package (pkz204g.exe), but using
it will not rectify any of the errors described in the above.
   If you are using a 386 or 486 computer, PKUNZIP may be having
some problems with your machine's BIOS. You can force PKUNZIP to
NOT use 386 instructions by doing SET PKNO386=ON at the DOS command
prompt to put the variable PKNO386 into your DOS environment.
   Furthermore, you can put a PKZIP.CFG file into the same directory
where your PKZIP.EXE program is. Below is an example of "cautious"
defaults (the spaces in front are just for FAQ readability).
       EMS=disable
       XMS=disable
       DPMI=disable
       NET=disable
       COMPRESS=maximum
   There also is a Unix version of unzip in case you wish to look at
the package already at your Unix host. See Item #5 for the pointer.
If you do not know how to handle tar.Z files, start by reading
ftp://garbo.uwasa.fi/unix/ts/tarzfaq.txt for the instructions to
make operative a utility distributed as a tar.Z. (A tar.Z file must
be transferred as binary.)

 A3: Be warned that there are countless bogus PKZIP 1.20, 2.0, 2.02,
3.05 and whatever scams floating around. They usually are hacks of
PKZIP 1.93A beta test version. Some of them are trojans and / or
carry computer viruses. There is one exception, 2.06 for IBM (the
company), but it is equivalent to 2.04g.

 A4: The most common error with .zoo is using the old 2.01 version
instead of the current version 2.10. Likewise, for the other
archivers, make sure that you have the most recent version.

   All the best, Timo