Phantom Partitions

I just lost all the Data off of a Hard Disk I was Using.
It was during an xcopy from one directory to another.
The copy failed, probally due to bad cluster( which I found
later). However, after the crash, I could no longer access
the disk. An Invalid Media type Error was returned. I checked the
bios and it reported the correct  CHS values and capacity, which was
540 megs. However, when I ran FDISK, the partion information said
Active, Primary Dos, 520 megs, 100% usage.

Undeneath, the summary said total disk space 504 megs.

I tried FDISK /MBR, SYS, but none would overcome the Invalid Media type.
I figured I had head crash on the boot sector so with nothing to loose I
formatted the disk. It formated fine, I placed the system back on and away
it went. When I ran Norton Disk Doctor on it , Norton asked me If I had
a partition I could fromerly acces but now can't as iff there was a "Phantom
Partion" defined. I defined no such partion. It was always a 1 partion drive.
Norton also said it could not report drive characteristics as the HD was not a
physical drive???

Now I am concerned that If I fill the drive up with data the crash will occur again. Norton locked out the bad sectors and the drive seems to work.

Finally, brings me to my question, if your still with me!
Why does My Bios report the proper CHS values and capacities
while FDISK reports another? Also, what would have caused a
seemingly safe procedure such as coping files to wipe out a partition
or make a drive unreadable?

Who is Participating?
RoadWarriorConnect With a Mentor Commented:
Bios may be reporting the Physical specs of the drive, what you see in Fdisk is the translation supplied to the computer, it is a work around to get over an old bios/system limitation of not supporting drives with more than 1024 cylinders or bigger than around 500 Mb. This workaround is known as LBA (Large Block Addressing) mode, usually it will be seen as a halved number of cylinders and a doubled number of heads.

The size differences are due to different definitions of "Megabyte" 540 Mb reported in Bios is the maximum UNFORMATTED capacity. Then Fdisk is calculating megabytes as 1,000,000 bytes, and Dos is counting megabytes as 1024x1024 bytes.

I have come across previously unseen timing issues when large files are copied, this can make the drives firmware crash, it can also be caused by a minor, momentray glitch due to a bad contact on the IDE cable, in this case, often only the FAT in memory is trashed, if the FAT is cached at this point. If the system is still up and running, the important thing to do is not to panic and go firing off disk recovery utilities UNTIL you have rebooted with a power off reboot. Sometimes this will cure the temporary problem and leave you with just a couple of soft bad sectors where the copy failed when writing corrupted data, however, you should take a good look at sytem board timing, memory timing, cache timing and CPU and case cooling etc and check out the data cables and connections. Check also the block tranfer mode settings and 32 bit transfer settings in Bios, some drives don't like some IDE controllers and these settings may have to be disabled. If this drive was originally set up on another computer, (Fdisked and formatted) that also may be a cause of trouble, very slight variations of format can occur, which are not realised until large file transfers are tried, or the disk begins to get a certain percentage full.

However it could also be caused by pre-existing bad sectors, although this does not often cause the loss of the FAT. Unless the bad sectors were in the area where the FAT was of course. It would seem odd if this were the case, that the system had not exhibited some odd behaviour before that, i.e. files often dissappearing etc. If this had been the case, upon reboot, running scan disk would have given you the option to replace the FAT from the backup copy, as it would have detected it was corrupt. When you ran Fdisk /MBR it merely copied bad data over bad data I believe.

Best way to proceed for safetys sake for future operation is to delete all partitions, repartition to the max size of the drive, if you just want one, and then format again. Try making some large files on the drive and scandisk them, (making a drivespace or doublespace compressed volume is a good way to do this) and if you get problems, start looking at your hardware, connections first, then settings.


Road Warrior
You said that you re-formatted the drive, but you didn't mention re-partitioning it. You should have run fdisk, deleted all partitions, and created a new "cherry" one and then formatted. This would probably make all your problems go away. Did you fdisk before formatting?

Norton's was probably seeing the messed up partions and doing the best it could to report the errors. The file copy errors were also probably due to the lost cluster, as you guessed. If you've got an invalid file allocation table you're liable to get all kinds of screwy errors, up to and including trashing your whole drive.

Run fdisk, delete the old partition, create a new one, reboot, format. THEN run your Norton's or Scandisk or whatever to see if you're getting errors. You probably won't. Then it's safe to start installing your OS and applications.

Good luck


tandyAuthor Commented:
Thanks for your responses.

To tjoiner(Tim),
I did not repartition. I tried a format thinking
the drive had hard errors in the boot or fat.
After I found the drive was still good, I restored
the backup and have started restoring other
programs lost. I think I may re-partition though.
I resisted that  procedure as I try to live by
the addage "If it ain't broke , don't fix it", however
as I am reading your comments it seems that may
be the only way to prevent it from happening again.

Thanks for your response,

To RoadWarrior,
The bios is reporting exactly the CHS values
and capacity stamped on the drive. I thought
this was a sure indication that no sector
translation was occuring. Is it possible for a
bios to properly auto detect and display
CHS values, yet use other translation geometries
in the background? The computer  definitely has
a bios limitation, but I thought it was right at the
max, which is 540.  You are right about the drive
being FDISKED on another computer. The other
computer had no Bios limitation.

I was vaguely aware of the different definitions
of the megabyte. The 540 of the bios is based on the 1024 method is, it not?  Wouldn't that cause
fdisk to report a higher number (540*1024/1000)?

The large file copy was exactly what was occuring
when it crashed. I never considered timing issues
or bios hardware failure. If that is the cause the
drive may have problems with any config.

Unfortunatley It is too late with the panic situation. Like I said, I formatted thinking the
drive was bad. It only got interesting when I
found out the drive was "okay". This left me
scratching my head trying to figure what went wrong.

As regard to bios settings, they are quite limited.
It is an older bios from a time when auto detect
was considered high end(486 dx 33--ami bios 1992).  The only hard disk choices are user defined for CHS.

I ran fdisk first after the bios setings seemed okay. Then fdisk /mbr, then SYS C:. I did not
run Norton until after I had re-formatted the drive.
After FORMAT  recovered the drive I began to wonder why fdisk/mbr or sys had not cured the

In any case, as with Tim's answer, To be sure
the drive is set proper for the host machine,
FDISKING with the host is the securest. These
days though it is not uncommon to be swapping
drives like hot cakes. FDSIK is not an option when
you need both the data and the drive.

That was the situation in this case.
Thanks  of your answer detailed responses.
I have copied them to my info file,



Improved Protection from Phishing Attacks

WatchGuard DNSWatch reduces malware infections by detecting and blocking malicious DNS requests, improving your ability to protect employees from phishing attacks. Learn more about our newest service included in Total Security Suite today!

One more thing. Because your drive is on the 540 MB limit, it may be recognized as either LBA or standard CHS. Watch the BIOS setup and see what it shows. This may cause problems when moving it to another machine, or if the BIOS default changes. You should mark on the disk, how the BIOS was setup duing FDISK/format.
540 MB drives are pretty old, and it is probably near the end of it's useful life. Make sure any important data is backed up.
I hope this helps.
The sticker on the drive will almost always be smaller than what FDISK reports since FDISK takes formatting into account.  Depending on whether the manufacturer uses the same way as BIOSes do for counting then the sticker and BIOS are only SOMETIMES the same.  

For example the sticker on my drive says: 9130MB and FDISK says the drive capacity is 8715MB.  BIOS reports that it is 8990MB.  This is all perfectly OK, and the differing number that you are getting are not symptomatic of a problem.

You've asked two questions in one, argh, this should have been a small points question and the part about why xcopy trashed your system should be a large points one.  :(  Beats me why xcopy trashed it, other than computer sometimes go haywire...  


PS - FDISK /mbr is NOT as thorough as it could be.  To really really wipe out miscellany partitions, get ahold of a linux boot disk and use its fdisk to clean the drive.  If this method can't get rid of phantom partitions and everything then the drive is question is getting squirrelly.
oops, modify first sentence above with: sticker on drive is usually LARGER, not smaller
tandyAuthor Commented:
The problem is a combinaion of Drive, controller
and bios. After looking up some info on the
situation I find out about support sizes:

BIOS Limitation                              
C:H:S  1024:16:63        528M (dec)  504(bin)

Hard Drives Auto detect Geometry
C:H:S  1057:16:63        540M(dec)  520M(bin)

Although the bios read the autodetect info
and showed it in the summary, it could not
in fact store values this large. As a result,
it has to use 1024:16:63.

The Os, through Fdisk has to choose the
lowest common denominater which turns
out to be the bios in this case.

I think Norton ran the same auto detect
routine and found the higher values. When
it compared the Theoretical Max of the drive
to the bios report it figured the difference was
a lost partition. Which in a sense it is, lost
because the bios can't access it.

Still not quite sure why dos would write
over the Fat or Data areas...I will have to
copy some large files to see if it is a hardware
timing thing.

Thanks all,


Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.