We used a rather small drive (only 540 MB; see details below) for our experiments, and the whole drive was filled with zero bytes (using Maxtor's MAXDIAG.EXE) then checked at various locations with a disk editor to make sure the drive had actually been zero-filled (or cleared). Following this, an arbitrary number of sectors (the first 92,260 consecutive) were then filled with a 5Eh byte (personal choice; it's also the ^ character in ASCII), so we could make sure that any zero bytes written by FDISK could also be identified.
Test
Drive Used:
A Maxtor 7540AV (1046 Cylinders, 16 Heads, 63
Sectors)
Drive has: 1,054,368 Total Sectors, or 539,836,416 bytes;
approximately 539.8 MB or exactly 514.828125 BinaryMB (MiB).
The experiment was repeated with the MS-FDISK
(file date/time) from:
1) Windows 95B Boot diskette (08/24/96 11:11AM ver. 4.00.1111 with a
Y2K updated COMMAND.COM dated 02/19/99 10:55am),
2) Windows 98 Emergency Boot Diskette (05/11/98 7:01PM; ver. 4.10.1998)
and
3) Windows 98SE Emergency Boot Diskette (04/23/99 10:22PM; ver. 4.10.2222).
Each time, FDISK was set for "Large Disk Support" (32-bit FAT); which
Microsoft recommends using on drives of 512 BinaryMB (about 536.87MB) or more.
The results were the same for each version.
FDISK /STATUS
NOTE: Although it's possible
to safely use FDISK to check a drive's currently formatted partitions, it's
much safer to use the command:
FDISK /STATUS rather than run the risk of accidentally pressing
the wrong key (using FDISK interactively) and overwrite some of your sectors!
[ Missing the correct key for "Display
partition information" and mistakenly bumping the
ENTER key a couple times instead (note that not every key on a keyboard is always
in perfect condition either!), will launch FDISK's "Verifying
drive integrity" routine as it starts to partition
your disk! ]
Once you tell FDISK to begin partitioning all or
part of a drive (even if you didn't mean to), it will start to perform its Verifying
drive integrity, with its nn
% complete
indicator on the same line. This takes place on the screen entitled:
Create
DOS Partition or Logical DOS Drive
As soon as this process begins, it
immediately starts writing sectors full of F6h
bytes to certain locations on your drive!
I confirmed this (many times over) by breaking out of the program (CTRL+C)
or pressing CTRL+ALT+DEL (forcing a reboot) before FDISK had a chance to proceed
any further. ( It took less than
10 seconds for this small drive to complete this phase of the FDISK process!
All I can say if you suddenly realize
you're doing this to the "wrong drive" is to reboot (whichever
way you prefer) as quick
as you can! If you catch it at less than about 20% to
30% you might still have an intact second copy of the FAT to use;
the quicker you act, the better off at any point during this process).
It writes to and verifies (reads back) sectors
full of F6 bytes
on your hard drive; I don't know if it does both for each sector written
(that would be best for anyone who
makes a mistake and tries to catch it in time) or if it writes all of
them first, and then does the verification as part of its % count.
These "F6 sectors" are written to the 1st and 7th sectors
of each "Head" number (except for Head 0) until a calculated
number of sectors (depending upon the size of the partition) at the beginning
of the drive (or partition) have been "verified" by FDISK.
[ Some would call this damaging the drive's data
(rather than 'verifying its integrity'). Why? Because not all
FDISK programs act this way! As a matter of fact, many of them will only
write to the MBR or EBRs; Linux's fdisk program, for example, is a non-destructive
fdisk. ]
The F6-Sectors that MS-FDISK wrote to our 540MB Drive
Absolute
Sectors (C,H,S values)
|
Absolute
Sectors (C,H,S values)
|
||
63
|
(0,1,1)
|
69
|
(0,1,7)
|
126
|
(0,2,1)
|
132
|
(0,2,7)
|
189
|
(0,3,1)
|
195
|
(0,3,7)
|
252
|
(0,4,1)
|
258
|
(0,4,7)
|
315
|
(0,5,1)
|
321
|
(0,5,7)
|
378
|
(0,6,1)
|
384
|
(0,6,7)
|
441
|
(0,7,1)
|
447
|
(0,7,7)
|
504
|
(0,8,1)
|
510
|
(0,8,7)
|
573
|
(0,9,1)
|
579
|
(0,9,7)
|
636
|
(0,10,1)
|
645
|
(0,10,7)
|
.
. .
|
.
. .
|
.
. .
|
.
. .
|
These
continue in the same pattern as above, past the last
Head (31*) of Cylinder 0 and into Cylinders 1 and 2 : |
|||
1953
|
(0,31,1)
|
1959
|
(0,31,7)
|
2016
|
(1,0,1)
|
2022
|
(1,0,7)
|
2079
|
(1,1,1)
|
2087
|
(1,1,7)
|
2142
|
(1,2,1)
|
2148
|
(1,2,7)
|
.
. .
|
.
. .
|
.
. .
|
.
. .
|
3969
|
(1,31,1)
|
3975
|
(1,31,7)
|
4032
|
(2,0,1)
|
4038
|
(2,0,7)
|
4095
|
(2,1,1)
|
4101
|
(2,1,7)
|
4158
|
(2,2,1)
|
4164
|
(2,2,7)
|
.
. .
|
.
. .
|
.
. .
|
. .
.
|
4662
|
(2,10,1)
|
4668
|
(2,10,7)
|
4668
was the last sector
to be filled with F6 bytes.
|
|||
* The number of Heads, 32 (since the count begins with a 0), reflects the choice made by the BIOS of this computer when translating its given CHS of 1046, 16, 63 into one having no more than 1024 cylinders. Most drives today use all 255 heads in the Partition Table (yes, though it is possible for a byte to count up to 256, only 255 are used; see this note: Why MBRs do not use 256 Heads for the reason). Many drives that are larger than 8.4 GB have the values 1023, 254, 63 (for 1024 cylinders, 255 heads and 63 sectors) in their Partition Table. But I've seen Ending CHS sets with slightly smaller cylinder values. If you ever see a much larger value (such as 4096 cyl.), you need to know that's only an interpretation by the utility program you are using, since it's impossible to count past 1024 cylinders in a Partition Table! There are many variations in how the BIOS chips and/or disk utilities (such as Partition Magic) calculate CHS values these days. |
The next screen you would normally encounter when using FDISK to set up a hard drive is titled: Create Primary DOS Partition which asks the question, "Do you wish to use the maximum available size for a primary DOS partition and make the partition active (Y/N)............? [Y]" Once you press the ENTER key, FDISK repeats its Drive Integrity process once again! You'll see the same "Verifying drive integrity, nn % complete." line at the bottom as you did before. It may be that FDISK goes over the same exact sectors listed above twice, but since I can't run this part of the program without first going through the part above, there's no way I can say for sure.
During this last phase of the partitioning, FDISK writes its version of the MBR code to the very first sector on the drive (even if it already exists!) and enters the new partition's data into the Partition Table. For a view of every byte of the code that the MS-DOS 7.1 FDISK program writes to the MBR, take this link.
MS-FDISK wrote the following data to this drive's Partition Table:
Starting loc Ending loc Relative Number of # Type Boot Cyl Head Sec Cyl Head Sec sectors sectors - ------------ ---- --- ---- --- --- ----- --- -------- --------- 0 FAT-32(0Bh) Yes 0 1 1 521 31 63 63 1,052,289
You may see Type 0Ch ("FAT32 LBA") here instead. When MS-FDISK is run on a computer with a somewhat older BIOS, it may still reserve all the space in the last cylinder of a drive (about 1MB for this one) for the now archaic "test cylinder" (apparently for some kind of compatibility reason). But, when you partition the same drive on a computer that has a modern (usually made in 2000 or later) BIOS chip, it should use the whole drive for the partition; producing these results:
Starting loc Ending loc Relative Number of # Type Boot Cyl Head Sec Cyl Head Sec sectors sectors - ------------ ---- --- ---- --- --- ----- --- -------- --------- 0 FAT32(0Bh) Yes 0 1 1 522 31 63 63 1,054,305
At this point, it also warns you that you must reboot for the new partition data to take effect on your system. When you do, the OS will recognize the partition and DOS (or Windows) will assign it a logical drive letter. If this was the only drive on the system, once you reboot with a diskette again, you can even enter C: at the DOS Prompt and have C:\> appear on the screen, but trying to read any data from this new partition (such as entering, DIR C:) will cause that horrible DOS error message:
A:\>c: |
to appear. You can take this next link to read about "What Does Win 9x's MS-FORMAT do to your Hard Drive?" (Before you can actually store files in any new partition, you must also FORMAT it.)
The major problem with MS-FDISK: It was purposely designed (or so it seems at least) to destroy the means of being able to access any data that was stored on the drive prior to using it! And if it wasn't bad enough that FDISK writes F6-sectors all over both copies of the FAT (File Allocation Table), it also overwrites sectors in the Root Directory and may even overwrite some of your Data too! This is why MS-FDISK is so dangerous to your data, if used incorrectly!
Because of the difficulty of getting back any files that are kept in the Root Directory, it's a very good idea to store important data files in a subdirectory one or two levels down from the Root (note how MS-Windows does this with its "Program Files" subdirectory), since each Application will have their own 'directory file' to rebuild lost data from! This is why commercial software programs such as RunTime, Inc.'s "GetDataBack" can retrieve many of your files after an 'FDISK and/or FORMAT accident' occurs. Remember, there's a very low probability of recovering a file if it's being stored in the Root Directory if its directory data is close to the start of the volume's Data area. Like many other things in life, it's safer not to be too close to any boundaries (like a fish at the edge of a school in shark infested waters, or someone walking on a ledge 200 meters high with no safety net).
[ We may expand on the single drive example presented here at a later date, but the data above should be more than adequate for an understanding of what MS-FDISK does. ]
Last Revised: 3 August 2004.
You can write to me using this: online
reply form.
(It opens in a new window.)
Back
to: Detailed Notes on MS-FDISK
MBR
and Volume Boot Records Index
The Starman's Realm Index Page