At 03:11 PM 7/21/2005 +0000, Mark wrote:

I'll try that.  I'm only willing to run this on the one computer...too
risky for any others.  I'm not blaming fdisk, but do not consider
running it safe.  If I do not run fdisk, the disk partition table does
not get destroyed!

Well, maybe I'm wrong and being an idiot, but here looks like a serious problem in the FDISK code:

When you invoke FDISK without arguments, it goes into the Interactive_User_Interface() routine. That, in turn, asks about FAT32 support, via Ask_User_About_FAT32_Support() function. OK so far. After that call -- without any further prompting -- FDISK calls the Create_MBR_If_Not_Present() routine.

NO. Please, no. You should never write to the hard disk for low-level stuff like partitions and master boot record data without warning and giving the user a chance to abort or decide not to do it.

We know your particular FDISK run image was sick before the Create_MBR_If_Not_Present() call because you were getting garbage on the Ask_User_About_FAT32_Support() prompt. That means blown stack or overwritten data area, most likely overwritten data. And that means that FDISK's partition table data could easily have been trashed too. It almost certainly was, given your final results.

Perhaps there is a reason FDISK need always create an MBR on startup if it can't find one. If so, someone please tell me why it is necessary or desirable. Does a "valid" MBR have to be written to the disk at startup to do anything at all with FDISK, and is there reasonable justification not to warn with possible abort before it is done? Otherwise it looks like a bad design decision. And if it is a bad decision, even should there be a bug somewhere else, the behavior should be fixed ASAP. Seems too dangerous for general users otherwise.

SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast.
Freedos-user mailing list

Reply via email to