page@ulowell.cs.ulowell.edu (Bob Page) (12/01/87)
[This is a bit long, but I think it's reasonable. ..Bob] spencer@eris () wrote: >For those who fear using Disk Doctor on their hard disk, I certainly do. I think the Amiga community was spoiled by DiskSalv, and would like to see CBM somehow buy it from Dave H for inclusion in the standard WB distribution. >take a look at Fill Disk by FNF on one of the Fish Disks. It writes >a file to the disk until the disk is full. This means that Disk >Doctor will no longer recover bits and pieces of deleted files. This is great, as long as you aren't trying to recover a deleted or otherwise broken file (simple things like invalid keys are OK though). Also, there is a LARGE danger in using Fill Disk if you have a scrambled disk (i.e. NOT A DOS DISK). Since the root block is probably mangled, you can have an INVALID BITMAP, but have it incorrectly marked as valid. FillDisk will gladly allocate all those sectors, and diskdoctor naturally won't work as you think it should. Also note of course FillDisk is useless on NOT A DOS DISKs, since you can't use DOS to grab sectors until the disk is validated. For "normal" problems with disks, like invalid keys and directory loops, FillDisk/Diskdoctor is a much better solution than Diskdoctor alone. But then, for "normal" problems, a disk editor is an even better (faster) solution - after you learned most of the inner workings of the file system, which would take you a couple of days... ;-) I found, after 4 days unscrambling my hard disk (DiskDoctor would have thrown away most of the files, by the way), many things about DOS I've never seen documented anywhere before (I don't claim to have seen everything published, either .. in fact, I haven't seen the Transactor article, which supposedly was quite good). I got bits and pieces from all the PD disk utilities around, and still am not through fixing my drive, although it's now a DOS disk, and I have most of my files back! I think I can eventually get the rest back, too. >I had a validating hard disk, and when that was done (20 minutes later), >Then I had a working hard disk. I always wondered what the disk validator did ... like HOW it worked. You can force a disk validation by running DiskChange DH0: (or whatever the name of your disk is). The steps are (this is from memory, I'm not at home), ignoring FLUSH, MOTOR and CLEAR requests: Get Boot Block (block 0). First four bytes should say "DOS0", where '0' is a NULL character, not the digit. The rest of the block is ignored, but is usually filled with "DOSx" in each longword, where x is the offset into the block. Get Root block (block maxblock/2). Should check out as a root block - first longword is 0x00000002, last (127) longword is 0x00000001. There are other sanity checks, and info for things like disk name and the bitmaps are received from the root block. Also there is a longword that shows if the bitmap is valid or not. It looks like it's INVALID if 0, and valid any other way. I've seen disks with values of -1 and 1, so I guess either mean OK. If the bitmap is OK, for each block that holds the bitmap, get the bitmap block. There is only one block for a floppy; 10 for a 20MB disk, Maximum of 26 bitmap blocks per partition. If the bitmap is invalid, manually traverse the disk looking for valid blocks (files, directories, file lists) and add each one found to the bitmap. There must be more the validator does but I haven't needed to know much more than this. The process of searching every block for valid blocks (to rebuild the bitmap) seems to take a lot longer than it should. It also of course updates info in the DOS tables. I like and dislike the file system - the redundancy it provides is invaluable when trying to put damaged files and disks back together. DOS provides headers for every block, for easy identification, hashing for quick lookups, block checksumming, parent block pointers, block sequence numbers, etc. It's really tough to lose a file if you know the details of the FS and know how to reconstruct it from the information provided. On the other hand, every block now has non-data that has to be stripped out - slowing down bulk-DMA reads, since you can't just DMA it into a buffer without processing it first. Also, the bitmap sectors are not allocated adjacent to each other (or even in the middle of the disk) or even spread evenly throughout the disk. The bitmap is too small and has NO redundancy, although it could be reconstructed (witness the Disk Validator). Maybe the thing I like the least about the [potential] reliability of the FS is there is only one root block -- no backup. If you trash it, you either are left to the whims of DiskDoctor of have to learn the FS the hard way. You can't even use DiskEd; it only works on floppies. I have heard there is a new FS being beta tested addressing some of these concerns, especially the "dos info in every data block" problem so DMA hard disks will really fly. Also the FS layout is different, so opening a file is a little slower but directory listings are really quick. Good news from the user's standpoint. How about redundant root blocks? How much info will be provided to reconstruct damaged disks? I noted with interest Dave Haynie's statement that a HD DiskSalv program would not surface (from him) until around the time 1.3 came out. He said it was because he was busy (which I don't doubt), but I suspect another reason is he doesn't want to work on another version when he knows it wouldn't work with the new FS, part of 1.3... I thought about putting together a "Definitive Inside Look at the AmigaDOS Filing System" but don't think it's worthwhile if we're on the verge of a new FS. Then again, if it can help one person restore her data from a trashed disk, it would be worth it. Can anyone at CBM discuss the time frame for the new FS appearing? ..Bob -- Bob Page, U of Lowell CS Dept. page@ulowell.edu ulowell!page "I've never liked reality all that much, but I haven't found a better solution." --Dave Haynie, Commodore-Amiga
daveh@cbmvax.UUCP (Dave Haynie) (12/02/87)
in article <2080@ulowell.cs.ulowell.edu>, page@ulowell.cs.ulowell.edu (Bob Page) says: > I noted with interest Dave Haynie's statement that a HD DiskSalv > program would not surface (from him) until around the time 1.3 came > out. He said it was because he was busy (which I don't doubt), but I > suspect another reason is he doesn't want to work on another version > when he knows it wouldn't work with the new FS, part of 1.3... Good guess, but I really am more pressed for time these days than anything else. Support for NewFS is independent of everything else anyway, as I still have to support floppies in the DOS format. Which is good for floppies anyway, as it looks more secure than the new format, even though it's slower. I've only killed my hard disk twice, but I've had quite a few floppies get clobber, coffeed, magnitized, etc. The other excuse is that I've been putting in Intuition stuff so you can run from the WorkBench, and I've speeded some things up. The problem is that there's really alot more that's just screaming to be done; feeping creaturism or whatever they call it. If only it paid a little better. But I guess there's something to be said for fame and good karma. > I thought about putting together a "Definitive Inside Look at the > AmigaDOS Filing System" but don't think it's worthwhile if we're on > the verge of a new FS. I'm not sure if things change all that much in the new system, but ya never know. At least I don't, until I tear into it. Oh, well, I hear a 68020 calling me. > ..Bob > -- > Bob Page, U of Lowell CS Dept. page@ulowell.edu ulowell!page > "I've never liked reality all that much, but I haven't found a > better solution." --Dave Haynie, Commodore-Amiga NOW THERE'S A WORTHWHILE QUOTE! -- Dave Haynie Commodore-Amiga Usenet: {ihnp4|uunet|rutgers}!cbmvax!daveh "The B2000 Guy" PLINK : D-DAVE H BIX : hazy "I can't relax, 'cause I'm a Boinger!"
page@ulowell.cs.ulowell.edu (Bob Page) (12/02/87)
I wrote in 2080@ulowell.cs.ulowell.edu:
>You can force a disk validation by running DiskChange DH0:
Arrgh! DON'T DO THIS unless the people who supply your
harddisk.device (or whatever your driver is called) says it's OK!
I realized DiskChange makes some NON-STANDARD calls to the driver.
When I say non-standard, I mean IORequests that are not part of the
basic and required functions for a device, like open, close, read,
write, etc. Each device can have its own non-standard functions
for special commands unique to that device.
DiskChange ASSUMES it is talking to a 5-1/4 inch disk device, which
happens to have the same non-standard commands as trackdisk.device.
It may be that your driver writer also implemented the trackdisk's
non-standard commands, but you DON'T KNOW what might happen when
DiskChange says "MOTOR OFF" to your harddisk ... it might mean
"FORMAT" to the driver!
So DON'T use DiskChange DHn: unless you are sure it's OK. It's OK for
CLtd drives (they tell you about DiskChange in their documentation), I
suspect it is OK for everybody else's drive too, but make sure before
you do it.
If you are hanging on to my last article about disk validation, make
sure you hang on to this one too. Sorry I didn't realize the danger
before I posted the article.
..Bob
--
Bob Page, U of Lowell CS Dept. page@ulowell.edu ulowell!page
"I've never liked reality all that much, but I haven't found a
better solution." --Dave Haynie, Commonkeave to aandy@cbmvax.UUCP (Andy Finkel) (12/03/87)
In article <2080@ulowell.cs.ulowell.edu> page@swan.ulowell.edu (Bob Page) writes: >one root block -- no backup. If you trash it, you either are left to >the whims of DiskDoctor of have to learn the FS the hard way. You >can't even use DiskEd; it only works on floppies. DiskEd works fine on hard disks. I use it all the time. > >I thought about putting together a "Definitive Inside Look at the >AmigaDOS Filing System" but don't think it's worthwhile if we're on >the verge of a new FS. Still sounds like a good article, though. >Then again, if it can help one person >restore her data from a trashed disk, it would be worth it. Can >anyone at CBM discuss the time frame for the new FS appearing? soon (I hope) -- andy finkel {ihnp4|seismo|allegra}!cbmvax!andy Commodore-Amiga, Inc. "Any sufficiently advanced technology is indistinguishable from a rigged demo." Any expressed opinions are mine; but feel free to share. I disclaim all responsibilities, all shapes, all sizes, all colors.
bryce@hoser.berkeley.edu (Bryce Nesbitt) (12/03/87)
In article <2085@ulowell.cs.ulowell> page@swan.ulowell.edu (Bob Page) writes: |>You can force a disk validation by running DiskChange DH0: | |Arrgh! DON'T DO THIS unless the people who supply your |harddisk.device (or whatever your driver is called) says it's OK! | |I realized DiskChange makes some NON-STANDARD calls to the driver. |When I say non-standard, I mean IORequests that are not part of the |basic and required functions for a device, like open, close, read, |write, etc. Each device can have its own non-standard functions |for special commands unique to that device. Huh?? Unless my brain is fried, DiskChange ought to be doing a ACTION_INHIBIT true then false (or the other way 'round). That is a standard packet. Now dos may follow up ACTION_INHIBIT with something as rude as TD_CHANGESTATE, TD_CHANGENUM and/or TD_PROTSTATUS, but none of those should give a harddisk.device fits. (I'm told ACTION_INHIBIT was indented to return success for removable media drives, and failure otherwise. I don't know the status of this.) |\ /| . Ack! (NAK, SOH, EOT) {o O} . bryce@hoser.berkeley.EDU -or- ucbvax!hoser!bryce (") U WARNING: hoser's spool directory eats a *lot* of mail. :-(
cmcmanis%pepper@Sun.COM (Chuck McManis) (12/03/87)
In article <2085@ulowell.cs.ulowell.edu> (Bob Page) writes: :I wrote in 2080@ulowell.cs.ulowell.edu: |>>You can force a disk validation by running DiskChange DH0: |> |>Arrgh! DON'T DO THIS unless the people who supply your |>harddisk.device (or whatever your driver is called) says it's OK! |> |>I realized DiskChange makes some NON-STANDARD calls to the driver. |>When I say non-standard, I mean IORequests that are not part of the |>basic and required functions for a device, like open, close, read, |>write, etc. Each device can have its own non-standard functions |>for special commands unique to that device. Actually, DiskChange never talks to the device directly. What it does is send an ACTION_INHIBIT(True) to the handler, which then takes the disk 'off line'. Then sends an ACTION_INHIBIT(False) to tell the handler 'you have a disk here now.' The handler will read in the root block, and if the BMVALID flag is not set, start the validator running on the disk. Therefore all disks can be 'DiskChanged'. If your disk reacts badly to this I would suggest either your driver is incorrectly written (very unlikely) or your hardware is broken. |>It may be that your driver writer also implemented the trackdisk's |>non-standard commands, but you DON'T KNOW what might happen when |>DiskChange says "MOTOR OFF" to your harddisk ... it might mean |>"FORMAT" to the driver! DiskChange should not be sending a MOTOR OFF command to the device, it shouldn't be talking to the device period, just the handler. --Chuck McManis uucp: {anywhere}!sun!cmcmanis BIX: cmcmanis ARPAnet: cmcmanis@sun.com These opinions are my own and no one elses, but you knew that didn't you.
page@ulowell.cs.ulowell.edu (Bob Page) (12/12/87)
bryce@hoser.berkeley.edu (Bryce Nesbitt) wrote: >DiskChange ought to be doing a ACTION_INHIBIT > >Now dos may follow up ACTION_INHIBIT with something as rude as >TD_CHANGESTATE, TD_CHANGENUM and/or TD_PROTSTATUS It might not be DiskChange directly causing the non-standard (trackdisk-specific) IO requests to be sent, but that's what is happening. If it's DOS that's turning ACTION_INHIBIT into calls to TD_*, we've got a bigger problem than I thought, since any program doing an ACTION_INHIBIT will cause this to happen. >but none of those should give a harddisk.device fits. Not if the writer of the harddisk.device knew that errant programs might assume everything is a trackdisk, and send those commands to it. What's TD_CHANGENUM to you might be HD_FORMAT to me! That's why they're listed as non-standard commands. The DOS should not send TD_* commands to any device other than harddisk.device, and neither should user programs. ..Bob -- Bob Page, U of Lowell CS Dept. page@ulowell.edu ulowell!page "I've never liked reality all that much, but I haven't found a better solution." --Dave Haynie, Commodore-Amiga
spencer@eris.BERKELEY.EDU (Randy Spencer) (12/15/87)
In article <2112@ulowell.cs.ulowell.edu> page@swan.ulowell.edu (Bob Page) writes: >What's TD_CHANGENUM to you might be HD_FORMAT to me! That's why >they're listed as non-standard commands. The DOS should not send >TD_* commands to any device other than harddisk.device, and neither ^^^^^^^^^^^^^^^ >should user programs. >..Bob Do you mean "TrackDisk.device"? -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Randy Spencer P.O. Box 4542 Berkeley CA 94704 (415)222-7595 spencer@mica.berkeley.edu I N F I N I T Y BBS: (415)222-9416 ..ucbvax!mica!spencer s o f t w a r e AAA-WH1M -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-