Paul-Andre_Panon@van-bc.UUCP (04/04/89)
I just got bit by what I consider to be a serious bug in the 1.3 Format
command. What is the one thing a format command should never do? Format
without confirmation of course!
Hypothetical situation. Joe User has a 1 Meg 2000 (or a 500) with only
one floppy (or two floppies but one is being used for a download). He realizes
he needs a new formatted disk. He's got a CLI/Shell open but is worried that
he may run low on memory and would like to still have access to the system.
So Mr. User puts his Workbench disk in df0: and types
run format drive df0: name Blank
So he can still have access to that CLI/SHELL although it might get messy on
the screen if he needs it since format constantly prints to that window. Now
because it's being run, format can't get input from the window. So does it
halt with an error message? Does it pop up a simple Auto requester asking
whether the correct disk is in the drive? NO! It starts formatting Joe User's
Workbench Disk (It wasn't write protected because he'd just recently edited
some script files). But Joe User is half asleep. He doesn't realize what
happened and thinks, "Hmm. must have pressed CR twice accidentally." So he
uses his quadmate's startup disk (The same way) and trashes it. At this point
light dawns and Joe User is seriously P.O.'d. Somebody at Commodore (R&D and
Q&A) seriously FUBAR'd when they let that one through.
Now, I don't know whether this bug was present in older versions of AmigaDOS
but it sure had better be gone by 1.4. The last thing we need now is for
Commodore to get a reputation for having a Format command that doesn't
prompt for user confirmation.
I don't have any bug report forms. Could some developer with the appropriate
form please fill it out?
In case you haven't guessed I found myself in the position of Joe User and
I don't enjoy spending >2hrs. to rebuild my (and my quadmate's) boot disks
the day before an exam.
-- Please don't reply according to the header, instead use: ------------------+
-- |
-- INTERNET: userpap1%UBC@um.cc.umich.edu |
-- UUCP: {alberta,watmath,uw-beaver,uunet}!ubc-vision!ubc-mts!userpap1 |
-- BITNET: userpap1@UBCMTSG ------------------------------------------------+daveh@cbmvax.UUCP (Dave Haynie) (04/06/89)
in article <2344@van-bc.UUCP>, ubc-cs!mtsg.ubc.ca!Paul-Andre_Panon@van-bc.UUCP says: > I just got bit by what I consider to be a serious bug in the 1.3 Format > command. What is the one thing a format command should never do? Format > without confirmation of course! [...stuff deleted...] > run format drive df0: name Blank Don't RUN programs that need console input. That's never going to work right. It would get confusing enough if you have several programs going, all generating output to the same CLI. It's pretty obvious that only one program at a time can get meaningful input from a CLI. For the program "Format", it's a supported (far as I know) feature that "Format <NIL: ..." will invoke Format without the prompt. This allows programs (for instance, a backup-to-floppy program) to call Format with the Execute() function. Not a bug, a feature. > So he can still have access to that CLI/SHELL although it might get messy on > the screen if he needs it since format constantly prints to that window. Nope, that just isn't going to work. I don't know what the Shell would do in this case, though I have a theory. There are really 4 things that could happen: [1] CLI gets the input stream, Format gets NIL: In this case, you'll get just what happened with your setup. And from Format's point of view, it's doing the right thing. From your point of view, the RUN was wrong. [2] CLI gets NIL:, Format gets the input stream. In this case, the RUN would have been pointless anyway. [3a] They both get the input stream. In this case, even if Format waited for you to type RETURN, it would pause as soon as you typed anything else. The RUN was the wron thing to do. [3b] They both get part of the input stream. This has all the disadvantages of [3a], and no advantage. > Joe User is half asleep. He doesn't realize what happened and thinks, > "Hmm. must have pressed CR twice accidentally." [...] If Joe User is half asleep, he'd be much better doing something other than working on his Amiga. If you need ARE YOU SUREs and the like, use the WorkBench interface; it's specifically intended for novice users who often make mistakes. > -- INTERNET: userpap1%UBC@um.cc.umich.edu | > -- UUCP: {alberta,watmath,uw-beaver,uunet}!ubc-vision!ubc-mts!userpap1 | > -- BITNET: userpap1@UBCMTSG ------------------------------------------------+ -- Dave Haynie "The 32 Bit Guy" Commodore-Amiga "The Crew That Never Rests" {uunet|pyramid|rutgers}!cbmvax!daveh PLINK: D-DAVE H BIX: hazy Amiga -- It's not just a job, it's an obsession