Hi!
27-Июл-2006 04:48 [EMAIL PROTECTED] (Eric Auer) wrote to
freedos-devel@lists.sourceforge.net:
>> 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.
>> 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).
EA> /* Create Master Boot Code if it is not present */
EA> void Create_MBR_If_Not_Present()
EA> {
EA> Read_Physical_Sectors(0x80,0,0,1,1);
-----------------------------^^^^ !
EA> if( (sector_buffer[0x1fe]!=0x55) && (sector_buffer[0x1ff]!=0xaa) )
EA> {
EA> Create_MBR();
---------^^^^^^^^^^ ?
EA> }
EA> }
EA> This is called very early in
EA> void Interactive_User_Interface(),
EA> right after Ask_User_About_FAT32_Support,
EA> without asking the user.
It is/will fine is Create_MBR() will not write result until program
exit and empty table should be used only as "placeholder" for non-founded
MBR. But strange, that only 0x80 disk is checked, notwithstanding if there
more than one or none disks (or if there is read errors).
Well, I check FFDISK sources... Create_MBR() replaces boot code, adds
signature and not touches partition table area. Strange logic - if there is
no valid MBR, then partition table area also should be cleared. But all this
should be done in internal buffers.
EA> Several users have lost their boot loader,
You wish to say, that some boot-loaders don't have MBR signature?
EA> some even their partition table (see below),
EA> because Create_MBR_If_Not_Present fails
EA> to check for Read_Physical_Sectors errors.
EA> It just trusts the buffer contents. Oops.
Oops.
EA> Even if it WOULD check for errors, it is
EA> still a very bad idea to automatically
EA> jump to Create_MBR: That function again
EA> reads the MBR, inserts the CODE and the
EA> signature, but leaves the partition table untouched.
Agreed, that this is not logical.
EA> The problem is that "read error plus
EA> code fixed plus partition table left as is
...ie. garbage in case of missing MBR or read error.
EA> plus write changes back to disk" in
EA> the end means that the partition table will be destroyed.
But what wonder me: if there is no MBR, then garbage should not destroy
anything, so partition table (PT) will be destroyed only in case of read
error. BUT! Read error (of MBR) is sparse thing and it anyway makes disk
unusable - so how current FreeFDISK behavior will destroy PT?
EA> Only humans should be allowed to judge
EA> whether their MBR actually has to be rewritten.
Agreed.
EA> Another issue is that Linux still tends
EA> to use the MBR to store part of the boot
EA> menu (I usually tell it to use the Linux
EA> partition for that instead, but the
EA> default still often is using the MBR),
EA> so even replacing only the CODE part of
EA> the MBR is a bad idea when done without user interaction...
But this happens only if there is no signature! Do you wish to say,
that this menu (in MBR on primary hard disk! how these systems boot?)
doesn't accomplished by signature?
EA> My suggestion is simple: Do not modify
EA> any MBR contents without explicit request
EA> from the user. Or, if you have to present
EA> suggestions for changes, at least ask the user for confirmation...
Agreed.
-------------------------------------------------------------------------
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
