> EA> You said that the "if no MBR 55aa found, replace ALL code and
> EA> partition data in the MBR with an empty MBR" function in FDISK,
> EA> which has caused a lot of data loss in the past, would be
> EA> necessary to handle wiped / new / virtual harddisks properly.
> EA> Who would like to help me to find a better solution, for
> EA> example using his virtual computer?
>
> May you specify problem more precise?
>
> 1. Does this mean, that currently FDISK automatically wrote own MBR with
> empty partition table, when it finds "no signature"? If yes, this is
> bug - FDISK should ask before any write to disk (on exit from it).
/* Create Master Boot Code if it is not present */
void Create_MBR_If_Not_Present()
{
Read_Physical_Sectors(0x80,0,0,1,1);
if( (sector_buffer[0x1fe]!=0x55) && (sector_buffer[0x1ff]!=0xaa) )
{
Create_MBR();
}
}
This is called very early in
void Interactive_User_Interface(),
right after Ask_User_About_FAT32_Support,
without asking the user. Several users
have lost their boot loader, some even
their partition table (see below),
because Create_MBR_If_Not_Present fails
to check for Read_Physical_Sectors errors.
It just trusts the buffer contents. Oops.
Even if it WOULD check for errors, it is
still a very bad idea to automatically
jump to Create_MBR: That function again
reads the MBR, inserts the CODE and the
signature, but leaves the partition table
untouched.
The problem is that "read error plus
code fixed plus partition table left as
is plus write changes back to disk" in
the end means that the partition table
will be destroyed.
Only humans should be allowed to judge
whether their MBR actually has to be
rewritten. In the particular cases,
there were troubles with disk access,
and users would have noticed that FDISK
had those and would have aborted rather
than using FDISK in that situation.
Another issue is that Linux still tends
to use the MBR to store part of the boot
menu (I usually tell it to use the Linux
partition for that instead, but the
default still often is using the MBR),
so even replacing only the CODE part of
the MBR is a bad idea when done without
user interaction...
My suggestion is simple: Do not modify
any MBR contents without explicit request
from the user. Or, if you have to present
suggestions for changes, at least ask the
user for confirmation...
> EA> - it should NEVER be the
> EA> case that FDISK automatically kills my MBR.
>
> Yes.
Eric
PS: I think Jeremy had a patch to make the
harddisk detection in fdisk more lbacache style,
and Blair also did use that patch for the
current fdisk version on the iso. One bug less,
fewer cases of "FDISK finds no disks".
PPS: See also bug numbers 960, 1056, 1095, 1197,
1760 on the list:
http://www.freedos.org/bugzilla/cgi-bin/buglist.cgi?query_format=specific&bug_status=__open__&product=Fdisk
Bugs 1452, 1738, 1740, 1792, (1827), 1838, (1858)
and 1899 are probably unrelated FDISK bugs.
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
