Jump to content

Corrected FDISK and FORMAT


Petr

Recommended Posts

Guest wsxedcrfv

It's complicated... FAT-32 always uses 3 sectors for the boot structure, however:

1) If the OS is MS-DOS,

LBA0 is the boot sector that loads IO.SYS and LBA6 is its backup;

LBA1 is the FSInfo sector and LBA7 is its backup;

LBA2 has the second part of the boot code (and is pointed to from within the code in LBA0) and LBA8 is its backup.

So LBA2 doesn't contain any data or parameters - just code? When (or under what circumstances) does any of this LBAn code get executed?

VFAT.VXD is compressed and inserted into WINDOWS\SYSTEM\VMM32.VXD.

Version 1998 is the original Windows 98 Version

Version 2222 is the original Windows 98.SE Version.

Version 2223 is the latest Windows 98.SE Update.

I have a Patch to correct this bug.

Strange. In my general-purpose Win-98se folder (where I have a copy of all win-98 files, unpacked all cabs, etc) I have vfat.vxd, with a file-date 4/23/99 (the typical date for all win-98se files) - except that it has a version number of 4.10.1998.

What improvement or fix did Microsoft do with version 2223? Does it also have this 1-TB bug?

Under what circumstances does this bug manifest itself? Is it dependent or does it involve the number of clusters a volume has? IE - can it happen if the volume is less than 1-tb in size if the volume has a cluster size smaller than 32 kb?

Link to comment
Share on other sites


Guest wsxedcrfv

It's called "bootsector" do you think that it's code will be executed when booting? :whistle:

I wouldn't have thought that every volume or partition on a drive needed it's own boot code, except for the master boot record.

Link to comment
Share on other sites

I wouldn't have thought that every volume or partition on a drive needed it's own boot code, except for the master boot record.

Yes, as said you are missing some basics.

The actual MBR (Master Boot Record) in the "usual" form of the MS operating systems (i.e. NOT a multiboot MBR).

Has FIVE main functions:

  1. hold the partition table data (four entries, each 16 bytes long) that represent addresses of the partitions
  2. hold the disk signature (four bytes) on NT/2K and later systems ONLY
  3. find which of the four entries has an active state (i.e. check that either byte 0x01BE, 0x01CE, 0x01DE, 0x01EE is 0x80)
  4. check optionally that the actual partition entry marked as "active" as per above is NOT "hidden" (i.e. that it's partition type does NOT begin with 1 or 2) (some MBR code versions will not work with hidden active partitions)
    http://www.win.tue.nl/~aeb/partitions/partition_types-1.html
  5. call the bootsector of the partition or volume makrked as active

Since it is called "Master" even semantically it implies that some "Slave" boot record must exist. ;)

If you use a boot-loader, like grub4dos, you can "by-pass" BOTH the MBR and partition bootrecord and directly load the OS kernel, an example for DOS 7.x/8.x (a.k.a. Windows 9x/Me), create a bootable floppy running grub4dos then, you can boot your DOS/Win9x on first partition of first hard disk INDIFFERENTLY with:

chainloader (hd0)+1

the above chainloads the MBR (which chainloads the PBR, which chainloads the kernel)

root (hd0,0)
chainloader +1

the above chainloads the PBR or bootsector (which chainloads the kernel)

root (hd0,0)
chainloader /io.sys

the above directly chainloads the kernel file

BUT you need anyway some data in the MBR (the partition table data) and in the PBR ( the BPB or Bios Parameter Block), and of course the "magic bytes" 55AA.

These are detailed in the given links.

But you can try creating a FAT32 filesystem with apps like the FAT32 Formatter:

http://reboot.pro/2959/page__st__7

and you will see at a glance which parts are needed in the bootsector to actually boot.

jaclaz

Edited by jaclaz
Link to comment
Share on other sites

It's complicated... FAT-32 always uses 3 sectors for the boot structure, however:

1) If the OS is MS-DOS,

LBA0 is the boot sector that loads IO.SYS and LBA6 is its backup;

LBA1 is the FSInfo sector and LBA7 is its backup;

LBA2 has the second part of the boot code (and is pointed to from within the code in LBA0) and LBA8 is its backup.

So LBA2 doesn't contain any data or parameters - just code? When (or under what circumstances) does any of this LBAn code get executed?

The Code is used when the particular Partition is booted from.

VFAT.VXD is compressed and inserted into WINDOWS\SYSTEM\VMM32.VXD.

Version 1998 is the original Windows 98 Version

Version 2222 is the original Windows 98.SE Version.

Version 2223 is the latest Windows 98.SE Update.

I have a Patch to correct this bug.

Strange. In my general-purpose Win-98se folder (where I have a copy of all win-98 files, unpacked all cabs, etc) I have vfat.vxd, with a file-date 4/23/99 (the typical date for all win-98se files) - except that it has a version number of 4.10.1998.

What improvement or fix did Microsoft do with version 2223? Does it also have this 1-TB bug?

Under what circumstances does this bug manifest itself? Is it dependent or does it involve the number of clusters a volume has? IE - can it happen if the volume is less than 1-tb in size if the volume has a cluster size smaller than 32 kb?

I checked my files. You are correct. The 98SE Version is identical to the 98FE Version except for the DateStamp.

The 2223 Version (KB277628) fixes a bug in a File Date Setting function. It still has the 1TiB bug.

The bug appears in some configurations when you try to access a Directory that is located more than 1TiB into the Partition. It is not affected by the Cluster size.

Link to comment
Share on other sites

  • 1 month later...

Hello all,

I have got a Hitachi 5K3000 2TB drive. It has 3.907.029.168 sectors of 512 byte size; thats 2000,4GB or 1.907.729,1 MiB. Let me just tell you what I have done:

I formatted the HD with Paragon Partition Manager 11 under XP USB ( 1 extended Partition and 1 logical drive). Under Win98SE that worked, but the drive could not be used under DOS and scandskw and defrag reported "not enough memory", as known. Also behavior of DOS scandisk was odd. Partition Magic 8 reported errors like "wrong order" and "partition does not start at cylinder boundary", although is seems to show the correct size of the drive. Probably Paragon Partition Manager 11 uses a new kind of partitioning scheme instead of the old CHS.

After that I used Free Fdisk 1.2.1 to delete that partition and made a new one. It reported total disk space 1.907.734 MiB and the extended partition had 1.907.721 MiB. I made 2 logical drives of equal size and formated the 1st one with format.com from BHDD31. This went through in about 2 hours and the partition was fine in DOS as well as in Win98SE. scandskw and defrag worked.

Next I tried again Norton Partition Magic 8 (the DOS version). To be successful I had to delete everything with fdisk. But then PM8 accepted the disk and reported 1.907.726,6 MB, which I think should be MiB and is 243201 * 255 * 63 * 512 byte. I was even allowed to partition it and I did a small 8MB primary formated FAT, followed by an extended with logical drive but unformated. This went through and the logical drive had 1.907.718,7 MB (MiB?). The 8MB primary was usable, but a sys D: failed and when reentering PM8 it did not accept its own work: error #110: partition table number of sectors is inconsistent. Free Fdisk 1.2.1 confirmed the work which PM8 had done and reported the same size (1.907.719 MiB).

Next again Free Fdisk 1.2.1: I deleted everything and made 1 logical drive with fdisk. This time it reported 1.907.719 MiB as size of the drive, which is same as PM8, but 2MB less than it did itself in the first step. I formatted this with format.com from BHDD31. It said "formatting 1.86G" ( 1860G would be correct) and after 3 hours the % counter wrapped around, but after 4 hours format was successful. The partition seems to be fine under Win98SE (size 1,81TB).

Wolfgang

Edited by Wolfgang16
Link to comment
Share on other sites

BTW, I posted my setup here

Now I figured out, what the error #110 in 16-bit version of PartitionMagic8 probably causes:

#110 Partition table number of sectors is inconsistent

The hard-disk partition table contains two inconsistent descriptions of the number of sectors on the hard disk. This error is serious if both DOS and another operating system use the hard disk. Because DOS uses one description and other operating systems may use the other, data loss is likely once the partition is almost full...

As far as I know there are no two descriptions of the number of sectors in the partition table. The CHS description is meaningless here. But its looks like they are still using it:

this is from the PM debug file:

Disk 1:  243201 Cylinders, 255 Heads, 63 Sectors/Track.
BiosExtensions: 0x2100 Subsets (0x00000001): Access
The BIOS supports INT 13h extensions for this drive.
============================ Partition Tables ==============================
Partition -----Begin---- ------End----- Start Num
Sector # Boot Cyl Head Sect FS Cyl Head Sect Sect Sects
---------- - ---- ---- ---- ---- -- ---- ---- ---- ---------- ----------
0 0 00 [ 0 1 1] 0C [1023 254 63] 63 3907024002 [Large Drive Placeholders]
0 1 1 46592 254 63 Actual Values
Error #110: Number of sectors in partition is inconsistent.
ucSectors = 3907024002
end - begin = 748516482

Obviously PM8 takes the "Number of Sectors" and calculates:

3907024002 + 63 = 63 * 255 * 243201

This is stored in 16-bit variables which results in

243201 - 3 * 65536 = 46593

This is displayed as "Actual Value" of Cyl. Now it calculates back:

46593 * 255 * 63 -63 = 748516482

This is now compared to the initial value which is wrong and gives error #110.

So PM8 only works with partitions up to 539GB. I can confirm that PM8 works with 500GB partitions.

The problem is also discussed here:

http://www.hwkb.com/Uwe/Forum.aspx/storage-hard-drive/3596/Partition-Table-Problems-Number-of-sectors-in-partition

There is it said that the 32-bit version of PM8 does not have this problem.

I like the GUI of PM8, it prevents me from entering something wrong. So its a pity that this stupid and senseless check restricts the usability of PM8. Nevertheless I was able to use it to partition my drive. I have now a small 8MB hidden primary and the big rest is divided into 2 logical drives of equal size, so that I am able to use scandskw. PM8 rejected to format FAT32, so I did it with fat32format under XP.

So I have 2 questions to the community

1. I used a partitioning program which has obviously problems with big drives, but I checked the partitions with Free Fdisk, Win XP partitioner, Paragon Partition Manager 11 and Easeus Partition Master 8. None of them reported an error. Is this safe now or can there still be a pitfall?

2. Initially I tended to prefer a modern partitioner, but the negative experience with Paragon Partiton Manger 11 let me hesitate. Do you think that modern partitioners can generate partitions which look faulty under DOS?

Edited by Wolfgang16
Link to comment
Share on other sites

  • 9 years later...

Here's a quick fix for German users:

While using the English version of FDISK.EXE or FORMAT.COM on a German keyboard layout/system, FDISK/FORMAT required you to enter "J" (for "Ja") instead of "Y" (for Yes) altough it displayed that you should choose between "Y" and "N".
This was very confusing, so I changed the FDISK/FORMAT executables accordingly, that it would now display and accept "J/N" as it is way more user intuitive (see attached file).

FDISK_FORMAT_fixed_de.zip

Edited by creopard
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...