MOLNARRM@UREGINA1.BITNET (Dennis Gorrie) (02/04/89)
This is a reply to an earlier posting. I tried to reply direct 3 times but failed miserably. I have also found that the German shareware program FASTDISK will trash WB 1.3 disks. I don't understand why AmigaDOS should guru when I try to get a 'dir' of one of these trashed disks. I would appreciate it if someone could tell me under what circumstances does AmigaDOS crash when doing a 'dir' of a corrupt disk. Dennis Gorrie <molnarrm at uregina1.bitnet> ' Happiness is a Warm Chain-Saw '
kalinowi@topaz.rutgers.edu (Kalin) (02/05/89)
>get a 'dir' of one of these trashed disks. I would appreciate it if someone >could tell me under what circumstances does AmigaDOS crash when doing a >'dir' of a corrupt disk. And another question along this vein: I was playing with WARP the PD disk compressor. I had a nifty power flux that stopped my machine cold. The point is that WARP really trashed the disk, and whenever you inserted it from then on ( CLI, Workbench, whenever) the sytem would bring up the requester: Disk Corrupt Task Held etc. Then <*WHAPPO*> GURU!!! Why the h*ll should my entire system crash just because the disk was corrupt? This is not a very "friendly" way of handling bad media. I experimented and found that any disk you partially unWARP to, is corrupted and causes a sytem crash whenever you insert it. In order to recover the disk, you have to start a format from the CLI, and wait until it says: Insert Disk to be formatted Inserting the disk earlier results in a GURU. Is this a bug? It sure isn't right...
hull@hao.ucar.edu (Howard Hull) (02/06/89)
This time I'll give everyone a break and list the advice first, then I'll go on with the commentary... If you put a disk into your Amiga and your Amiga comes up with a meditation alert, then remove the disk, and (after reboot) substitute a known good blank formatted disk in an available drive, then call up a disk editor (DiskEd or DiskZap are both good ones). Now put in the troublesome disk, re-determine the root block (if possible), read it in, and clear the BMFLAG at longword SIZE-50. (The BMFLAG should be at longword decimal 78 on an AmigaDOS floppy, I believe.) Write the root block back to the disk, and exit the editor. AmigaDOS should open the disk, find the BMFLAG is cleared, and then proceed to pounce on it with the Disk Validator. Most of the time this will succeed, clearing up whatever problem you may have had with the disk. So here's the commentary: I discovered fragile elements in AmigaDOS <-- see, no G. Do I got respect? when I stupidly tried to "bcopy" a block from one disk to another "nearly identical disk" with DiskZap. When I checked out of DiskZap I was instantly gonged by the Guru. Then I remembered that (in the name of speed) trackdisk writes the whole track, not just the block. A little more thinking about the problem and a quick look at Bantam's "The AmigaDOS Manual" (not necessarily in that order) revealed to me that the track I had copied contained the disk bitmap. I had swapped in a track containing an invalid bitmap (for the mounted disk, anyway), and this had included also the rootblock with a TRUE BMFLAG. It was then that I realized what was the programmers' method of providing for "the need for speed" in AmigaDOS - by following rules of consistency rather than (as Leo said in his recent commentary) "making the program bullet proof" by using elaborate internal checks (which would come with resultant degradation in the speed and the size of the system routines). At first I was upset about this, thinking as you did, something of the effect "It ought not to be possible to crash the system by merely inserting a disk!" But then, think of the price. So I suppose that's why we have rules. If everyone obeys them, things are quicker and simpler. We don't have anything in the society that actually keeps motorists from running red lights. If we find a motorist who does this consistently, we eventually gronk 'em. In the case of AmigaDOS we either re-format the disk, or kick serious bitmap with a file system rectification tool. The trouble with Warp and programs of that ilk is that they violate the "virtual semaphores" built into AmigaDOS by doing things non-atomically. In other words, all it takes is a power fail or a snatched disk, and *ka-wump* they are caught with a set BMFLAG and an invalid bitmap. Quite a lot in AmigaDOS is protected by a few early-on consistency checks (like checking the BMFLAG before reading disk blocks into template-oriented routines that rip right into it and DO THINGS based on what was read) and by appropriately atomic clean-up actions like not letting anyone do anything with the disk as a part of a file-write until the BMFLAG is cleared, the file is written, the bitmap is updated, and the BMFLAG is set again. For a newly inserted corrupt disk with a set BMFLAG, if the blocks are hosed, and addresses are computed with the available garbage, a GURU visit is the inevitable result. Howard Hull hull@hao.ucar.edu
bill@cbmvax.UUCP (Bill Koester CATS) (02/07/89)
In article <8902040631.AA03787@jade.berkeley.edu> MOLNARRM@UREGINA1.BITNET (Dennis Gorrie) writes: > >This is a reply to an earlier posting. I tried to reply direct 3 times but >failed miserably. > >I have also found that the German shareware program FASTDISK will trash >WB 1.3 disks. I don't understand why AmigaDOS should guru when I try to >get a 'dir' of one of these trashed disks. I would appreciate it if someone >could tell me under what circumstances does AmigaDOS crash when doing a >'dir' of a corrupt disk. > > WARNING CAUTION DANGER!!! I have had reports that FASTDISK is a trojan horse Proceed with extreme caution. -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Bill Koester (CATS) >>Commodore Amiga Technical Support<< Commodore International Ltd. UUCP {allegra|burdvax|rutgers|ihnp4}!cbmvax!bill PHONE (215) 431-9355 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= The official word, is NO. I am therefore going anyway! Kirk - Star Trek III Pleese desrigard eny spealing airors!!!!!!! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
sparks@corpane.UUCP (John Sparks) (02/08/89)
In article <5905@cbmvax.UUCP>, bill@cbmvax.UUCP (Bill Koester CATS) writes: > WARNING CAUTION DANGER!!! I have had reports that FASTDISK is a trojan horse > Proceed with extreme caution. Hmm. I have used Fastdisk with workbench 1.2 for almost a year and have not had any problems. What have you heard about Fastdisk that makes you think it's a trojan horse? how can I find out? I do know that it does not work under WB1.3, but it worked fine under 1.2 it seems to reorder the data on the disk to make accesses faster. _______________________________________________________________________________ John Sparks // Amiga | corpane : sparks@corpane a.k.a \X/ UUCP | blitter : john@blitter (preferred; path below) RedHawk ~~~~~~~~~~~~| {rutgers|uunet}!ukma!corpane!disk!blitter!john D.R.A.G.O.N.| >> call D.I.S.K. @ 502/968-5401 thru -5406 << Ye Quote: Build something that even a fool can use, and only a fool will want to use it. -- C. Shaw. _______________________________________________________________________________
bill@cbmvax.UUCP (Bill Koester CATS) (02/10/89)
In article <307@corpane.UUCP> version B 2.10.3 4.3bsd-beta 6/6/85; site cbmvax.UUCP cbmvax!bpa!rutgers!tut.cis.ohio-state.edu!unmvax!ncar!noao!asuvax!mcdphx!mcdchg!ddsw1!corpane!sparks sparks@corpane.UUCP (John Sparks) writes: >In article <5905@cbmvax.UUCP>, bill@cbmvax.UUCP (Bill Koester CATS) writes: >> WARNING CAUTION DANGER!!! I have had reports that FASTDISK is a trojan horse >> Proceed with extreme caution. > >Hmm. I have used Fastdisk with workbench 1.2 for almost a year and have not >had any problems. What have you heard about Fastdisk that makes you think >it's a trojan horse? how can I find out? It was just something I heard. I don't have a copy to verify. > >I do know that it does not work under WB1.3, but it worked fine under 1.2 >it seems to reorder the data on the disk to make accesses faster. It may be that it is not compatible with 1.3 and someone reported it as corrupting their hard disk. Just relaying what I heard. BK -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Bill Koester (CATS) >>Commodore Amiga Technical Support<< Commodore International Ltd. UUCP {allegra|burdvax|rutgers|ihnp4}!cbmvax!bill PHONE (215) 431-9355 =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= The official word, is NO. I am therefore going anyway! Kirk - Star Trek III Pleese desrigard eny spealing airors!!!!!!! =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
andy@cbmvax.UUCP (Andy Finkel) (02/10/89)
In article <307@corpane.UUCP> sparks@corpane.UUCP (John Sparks) writes: >Hmm. I have used Fastdisk with workbench 1.2 for almost a year and have not >had any problems. What have you heard about Fastdisk that makes you think >it's a trojan horse? how can I find out? I've seen the source to at least one of the programs calling itself FastDisk. It didn't seem to be a horse, but did seem to assume a lot of things about the workbench disk, including file names, and where the filesystem wanted to look, in what order. It looked into your startup-sequence to try to arrange programs on your disk in the correct order. It probably breaks under 1.3 because we changed the names of some programs. It may also have problems with the StartupII file, and resident confuses it completely. It will also break on 1.4 when the filesystem changes again. -- andy finkel {uunet|rutgers|amiga}!cbmvax!andy Commodore-Amiga, Inc. "Possibly this is a new usage of the word 'compatible' with which I was previously unfamiliar" Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.