Message-Id: <3.0.6.16.19990320121749.2e9f140e@highfiber.com>
X-Sender: raster AT highfiber DOT com
X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (16)
Date: Sat, 20 Mar 1999 12:17:49
To: dos DOT support AT caldera DOT com
From: Charles Dye <raster AT highfiber DOT com>
Subject: FDISK problems
Cc: opendos AT delorie DOT com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Reply-To: opendos AT delorie DOT com


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.

raster AT highfiber DOT com