On 21 Mar 00 at 5:44, Thomas Mueller wrote:
> I don't see how MS-DOS 6.22 made it out the door with FDISK in such
> sad shape, it doesn't run on my system at all. And MS-DOS can't
> read the FAT16 partition on my second hard disk ("Invalid media");
I think you may be barking up the wrong tree here. Did you FDISK
your system with DR-DOS 7.03 or Dr/Open-DOS 7.02? If so - your
problem might be related to a bug in Dr-Dos fdisk.
Below I copy the content of the bug report Charles Dye submitted to
Caldera and copied to the opendos list at delorie.com on Sat, 20 Mar
1999:
>>>>> # begin copy
Recent versions of DR DOS FDISK.COM contain errors which can result
in wasted disk space, volumes incompatible with MS-DOS and PC DOS,
and possibly even loss of data if MS-DOS or PC DOS is used to write
to such volumes. There are two issues: incorrect cluster sizes on
some hard drives, and a nonstandard OEM string in the BIOS parameter
block (BPB).
The problem can be demonstrated using a Maxtor 7120 hard drive, with a
geometry of 936 cylinders, 16 heads, and 17 sectors per track.
Alternatively, you can use any larger IDE hard drive; just set the
CMOS drive parameters to 936 x 16 x 17. Erase the boot sector (MBR
and partition table) to all zeroes and reboot. Use FDISK 2.13 from DR
DOS 7.03 to create a partition. Select option 1 (Create partition)
and then option 1 (Create DOS primary partition.) Accept the default
size. Reboot; you will now have a volume incompatible with MS-DOS
6.22. You will probably see garbage if you try to list a directory
under MS-DOS, and CHKDSK will report lost clusters.
This incompatibility has two causes. First, FDISK assigns an
incorrect cluster size. A volume smaller than 128 megs should use a
2K cluster, but FDISK creates 4K clusters. This is a bug in its own
right. The larger cluster size wastes space if you store many small
files instead of a few large ones -- the typical situation on a
DOS-based system with a smallish hard drive.
Second, FDISK puts an unusual OEM string in the BPB at offset 03h.
Older versions of FDISK used "IBM 3.3" (pretending to be PC DOS.)
Newer versions use "DRDOS 7". This is a problem because the OEM
string is not entirely cosmetic. MS-DOS and PC DOS use it to decide
which of the other fields in the BPB to "trust." If it's a known OEM
string, MS-DOS will use the BPB value for the cluster size (among
other things.) If the OEM string is not recognized, MS-DOS will
ignore the specified value for the cluster size, and compute the
correct size itself. If the "correct" cluster size does not match the
actual size -- as with that Maxtor drive -- then MS-DOS will also be
using wrong values for the FAT size, the start of the root directory,
the start of the data area....
The cluster size problem seems to have appeared in the 2.xx rewrite
for OpenDOS 7.02. The "DRDOS 7" string is more recent. I'm not
certain exactly when it first appeared, possibly in one of the beta
updates after DR DOS 7.02.
If you install DR DOS on systems, I recommend "falling back" to
FDISK v1.75 or v1.76 from OpenDOS 7.01 or Novell DOS until Caldera
releases a fix. These versions do not suffer from either problem, as
far as I can tell.
If you have created a partition using a recent version of DR DOS
FDISK and it turns out to be incompatible with MS-DOS, you may be able
to work around the problem by using Norton DiskEdit or similar to
change the OEM string in the BPB (logical sector number 0 of the
volume.) Use "IBM 3.3" (without the quotes, two spaces between IBM
and 3.3.) Your cluster size will still be wrong, however. The only
real solution is to back everything up and repartition.
Fixing FDISK: At the very least, the OEM string needs to reflect some
Microsoft or IBM release of DOS. "IBM 3.3" or "MSDOS5.0" would be
fine. But I would strongly recommend fixing the cluster size
calculation at the same time. As it stands, a Caldera DR DOS system
may run out of disk space significantly faster than an MS- DOS system
running the same applications.
[ email address omitted in this copy]
<<<<< # end copy
Next, copy of a fdisk status summary submitted by Chales Dye to the
caldera-opendos list on Wed, 21 Apr 1999.
>>>>> # begin copy
>What is the date and byte-size of the 7.02 Caldera fisk.com?
Here is my list. This includes only "official" versions; there
have probably been beta releases that I don't include. Sorry,
I have no info on the 1993 release, or on any version prior to
DR DOS 6.
File dates may not be a foolproof method of identifying files,
and the version numbers certainly are not. The 16-bit checksums
below are the ones reported by XDIR /C.
[ email address omitted in this copy]
Version From Date Size 16 Checksum 32 Status
R1.60 DR DOS 6 (old) 08-23-1991 17,487 48D6 ADA7C8A9 Cool
R1.75 NW DOS 7 (old) 01-26-1994 19,287 3C66 B2984A8E Cool
R1.76 NW DOS 7 (new) 11-29-1995 19,265 4EF2 BFE42549 Cool
R1.75 OpenDOS 7.01 02-27-1997 19,291 317F 665EE178 Cool
R2.02 DR-OpenDOS 7.02 12-19-1997 22,829 E800 D20BA555 #1
R2.02 DR-DOS 7.02 02-27-1998 22,827 F7F4 2E81EA9D #1
R2.13 DR-DOS 7.03 01-07-1999 28,150 12C6 B1C7991C #1 #2
Notes:
#1 - May use a larger cluster size than necessary for small volumes
#2 - May create volumes incompatible with MS-DOS
<<<<<<<< # end copy
If you want the full story (bug report, discussion, reply from
Caldera staff), get the April 99 archive for the Caldera OpenDos
list, and look for messages with fdisk in the subject line. You can
download the archive from:
ftp.lineo.com
pub/mail-archive/caldera-opendos
<snipped long dir listing>
541457 May 1 1999 caldera-opendos.9904
I believe there is also searchable (www) list archive for the
other(!) opendos list at delorie.com, but I don't have the exact
URL for it, Try: <http://www.delorie.com/djgpp/mailing-lists/>
Subscribe to the opendos at delorie.com at the above URL and post
your questions there (the caldera list seems to be gone).
Or to sub my mail, send
to: [EMAIL PROTECTED]
and use following syntax in body of message:
add your@email opendos
(notice: the word *add* is part of the command,
delorie listserv uses *add* instead of *subscribe*)
All the best,
Bjorn
