KR> in the case of losing the boot sector, you will lose your partition
KR> information, and i have yet to see a recovery from that that doesnt
KR> destroy all the data on the disk,

RS> Thats going a bit far. If you know the partition layout you can
RS> restore it from memory. Trivial if the drive has one partition for
RS> example. And trial and error is possible in some cases without losing
RS> data.

KR> you seem to have missed the point completely,

RS> Nope.

KR> well thats your opinion, mistaken though it may be.

Nope.

KR> i have no doubt that the partition table could be rebuilt, if (big if)
KR> you happen to know from which to which cylinder each partition on your
KR> hard disk goes.

RS> So losing the boot sector isnt always the end of civilisation as we
RS> know it, even in the extremely unlikely event of a power flick at
RS> just the crucial instant of execution of an FDISK /MBR. Thats quite a
RS> contrast to your 'destroy all the data on the disk' above.

KR> if you know the partition layout of your disk, and know the layout
KR> of the contents of the boot sector, you could certainly rebuild.

Which is why I originally said 'thats going a bit far' to your original
at the top. No opinion there.

KR> that lets out 99% of the population,

Oh crap, only 1% of hard drives only have one partition. Yeah, right.

KR> whose only option would be a full fdisk, and total data loss

Nope, there are still other options, even with more than one partition,
which may get the data back.

KR> i have no idea what they are on my disks,

RS> And I specifically said that in some simple cases like one partition
RS> per physical drive, it may well be quite trivial.

KR> in SOME cases it MAY be trivial, a lot of maybes.

Nope, just one, maybe the drive has only one partition. Quite a few are
like that.

KR> you stated that it is probably more important to back up the cmos as
KR> a lot of users dont know the disk type, if they dont even know their
KR> disk type, what hope have they of rebuilding the partition table.

Quite a lot of hope if their drive only has one partition on it.

KR> but why would you bother when all you need to do is to take a copy of
KR> the boot sector once only straight after you do the first fdisk when
KR> you set the system up.

RS> Pretty simple really, because most people arent sufficiently anal
RS> retentive to copy the boot sector to a floppy just for an FDISK /MBR,
RS> even if you are. Obviously you are welcome to even use kinky leather
RS> gear when doing an FDISK /MBR if you want to, but you were suggesting
RS> that saving it was the one true path to salvation. It aint. The risk
RS> is microscopic.

KR> oh shit, rods on the cliches again, same tired old crap, nothing more
KR> to say so throw in a few vague insults, covers up a lack of thought,
KR> and uses up space.

Oh shit, Keith is off on the juvenile debating technique stuff again.
Enjoying yourself are you ?

I repeat, the risk of a power flick at the time of doing an FDISK /MBR is
microscopic.

KR> the boot sector is one thing on your disk that should never change,

RS> So you claim. Most people dont agree with you, IBM included. You have
RS> yet to substantiate your assertion with any real evidence of a major
RS> risk either.

KR> who are these most people? you and who else?

IBM for one. And if you seriously think that most people actually backup
the first physical sector of their drive before they do an FDISK /MBR or
use the OS2 boot manager...

KR> since the boot sector consists of a simple bootstap program, and
KR> the partition table why should it change? obviously award dont
KR> agree, since their more recnt bioses watch for writes to it and
KR> complain loudly if they find one.

Thats for a completely different reason, virus detection. Not power
flicks when doing an FDISK /MBR. Funny that.

KR> so, to my mind, an extra 2 minutes spent when setting up a system are
KR> well spent even if you never need to use it.

RS> Well, as I say, you are perfectly entitled to do whatever you like.
RS> But you didnt jump into this thread to just inform us about your
RS> funky approach, you were indeed attempting to tell me that I should
RS> have told Paul about the risk. I dont agree, neither does he. Funny
RS> that.

KR> what paul said was that he wouldn't have done a backup, his original
KR> message was asking you why you had said it was an inocuous command,
KR> the implication being that he didn't find it so after finding out
KR> what was involved.

Missing the point utterly that his original question concerned the risk
of the FDISK /MBR in the sense of changing stuff like the partition
table ON PURPOSE not the power flick question which didnt even enter his
head at the time of the question.

KR> i dont suppose that many people do bother, thats ok, it is the sort
KR> of thing that brings me extra work.

RS> I doubt it. The vast majority of people dont do FDISK /MBRs anyway,
RS> its an undocumented command as you know, and they dont have a need
RS> to use it anyway, and the risk is utterly microscopic that when one
RS> is used, you will get a power flick at the time you do one. With
RS> that combination of unlikelys, I hope you dont plan to live on the
RS> income generated.

KR> nope, just from people who dont bother to take precautions in general,

Which is all a bit irrelevant in a thread about the dangers of FDISK /MBR

KR> still its good how they'll happily pay through the nose because
KR> disaster hits then go back to the same old attitudes. the anal
KR> retentives, of course dont get into that situation, and live
KR> happy lives with lower stress levels.

I havent said that proper backups arent extremely desirable, what was
being discussed tho was the risk to the first physical sector of an FDISK
MBR and stuff like a boot manager. An utterly different question.

KR> of course you dont do it just to guard against problems with fdisk /mbr,

RS> Which is what I said, that the risk of a problem with losing the cmos
RS> values is considerably higher and that its not a bad idea to generate
RS> say a Nortons Rescue disk. Thats an utterly different question to

(Continued to next message)

--- PQWK202