starner@ihlpg.ATT.COM (Guy Starner) (03/12/88)
Help! Two week ago I bought an A2090 card and a Seagate ST-251-1 (40 Meg, 28 ms). After less than a week, the disk became corrupted so that it wouldn't validate. The problem occurred while I was moving icons around in workbench. The system froze up and when I rebooted the validation failed! So I had to reformat the drive losing about 20 Meg and 2 evenings work in the process. After reformatting I started to repopulate the disk. Last night I found that one of my directories was corrupted. When I listed the directory a group of file start appearing repeatedly in the list. I deleted all files and directories from the corrupted directory except one which no DOS command can seem to find (except "list"). I would like to fix this problem by using a disk editing tool rather than reformatting. (I have put about 15 Meg back onto the disk.) The only disk editing tool that I have that seems to work at all with the hard disk is sectorama. (disked does not know about dh0:. diskdoctor, which I would rather not use in the first place, says that I don't have enough ram (1 Meg is not enough??).) However, what sectorama shows me does not match up with the file system description in the Amiga Dos manual. So my question is: how do the trackdisk.device and harddisk.device differ? It seems that they should look basically the same to Amiga DOS. Maybe the only difference is where the root block and bitmap are located (where are they?) and the size of the bitmap. Are the formats of the root, directory, file header and file data blocks the same? Also does anyone know if the new harddisk.device floating around on BBSs (which was created to solve overscan problems?) will help prevent the corruption problems I am having? Any help would be appreciated. Thanks in advance. Guy Starner AT&T Bell Laboratories Naperville, Il ...!ihnp4!ixlpn!starner -- Guy Starner IHP 2F-522, 416-7396 ixlpn!starner
lphillips@lpami.van-bc.UUCP (Larry Phillips) (03/12/88)
ere really a line eater?> In <5014@ihlpg.ATT.COM>, Guy Starner writes: >I would like to fix this problem by using a disk editing >tool rather than reformatting. As Chief Dan George said: "Sometimes the magic works, and sometimes it doesn't." It's always worth a try though. Sectorama is one of the better sector editors around, but sometimes refuses to write to the disk. >The only disk editing tool that I have that seems to work at all with >the hard disk is sectorama. (disked does not know about dh0:. diskdoctor, >which I would rather not use in the first place, says that I don't have > enough ram. It may depend on which version of DiskEd you have. Mine recognizes any disk device, including hard drives. It came from a Gamma version of 1.2. It would be awfully nice if CBM would release some of the tools that were available to developers. I feel very bad when someone asks me for DiskEd or Wack, and I have to say I not only can't give it to them, but that they can't even buy it. Your feelings about DiskDoctor are well deserved. I don't trust it at all, and do not have it on any disk that I can easily find. It can definitely clobber entire directory structures. >However, what sectorama shows me does not match up with the file system >description in the Amiga Dos manual. It should. It does on mine. First, make sure you are not using the first version released, which had a problem with partitioned disks. The earliest safe version (well, as safe as a sector editor can be), is 19192 bytes long (sorry, there doesn't appear to be a version number in it). >So my question is: how do the trackdisk.device and harddisk.device >differ? It seems that they should look basically the same to Amiga DOS. >Maybe the only difference is where the root block and bitmap are located >(where are they?) and the size of the bitmap. Are the formats of the >root, directory, file header and file data blocks the same? If you can do it, make a small partition on the hard drive, say 1 or 2 cylinders, and use it to play with Sectorama. Once you get to know the program and the file system, it becomes much easier, and a lot less scary, to go in and muck with the real data on a larger partition. The format of the individual blocks on a disk device is determined by Amigados (or at least the file handler, if that isn't considered part of Amigados). A root block is a root block, and the only thing about it that changes is the location. The root block is placed in a block approximately half way between block 0 and the highest numbered block. This is relative to the _partition_ and not to the entire disk. All other standard blocks may be found by starting at the root block and following the pointers. The bitmaps, for example, can be found by following the pointers located in the longwords at $4F (note that $4F is the hexadecimal offset IN LONGWORDS from the beginning of the block). The previous longword ($4E) contains the 'bitmap valid' information, and is normally all F's. You can force the disk-validator to rebuild the bitmap by making this longword all zeros, and running 'diskchange' from the CLI. To edit the longword, click on it and type an 'e', then type zeros, ending with a <RETURN>. Sectorama comes up looking at the root block of the disk specified in the command line, and you can get back to the root block at any time by typing an 'r'. The first order of business is to find the file you want to alter/delete/fix. To do this, at the root block, select 'Compute Hash Value' from the menu or by typing <right-Amiga H>. Click in the requester and enter the name of the file or directory you need. If a file is within a directory, you will need to find the directory first of course. After entering the name and hitting <return>, the hash value will be shown by the highlighted longword. Type 'j' to jump. The jump will be to the block pointed to by the highlighted longword, and should land you on either a directory or file header block. A directory header block has a similar structure to the root block, with a hash table pointing to subdirectory or file header blocks. If the header block you landed on is not the one you are looking for, it means that the name hashed out to the same value as the name of another directory or file, and in that case, you must follow the 'hash chain'. Type a 'c' until you see the name of the directory or file you are looking for. If a directory, repeat the 'Compute Hash Value' operation using the name of the next subdirectory or file name, following hash chains as before, until you arrive at the offending file. Now comes the part that isn't simple enough to just tell you what to do. You must decide what is wrong with the file itself, and what you want to do with it. If you are looking at the file header, and decide that you just want to delete it from the disk, you can type 'p', and go back to the 'parent' block, which should be either the root block or a directory header, then follow the chain again to the hash chain block _immediately_ previous to the offending block, and zero out the hash chain entry (this an be found at longword offset $7C) . This will remove the file from the directory structure, but keep in mind that it will also remove any files farther down the same hash chain. If there are files farther down the hash chain, you will have to bypass the offending file by manually entering the pointer to the next file after the bad one. If you want to completely clear out the directory, just zero out all hash table entries (longwords 06 through 4D inclusive), in the directory in question. Note that doing this in the root block effectively formats the entire partition, removing all files from the directory structure. If your problem is obvious from looking at the header of the offending file, you can use 'e' or 'a' to edit the contents of the file header itself. In any case, once you make any change to either a directory or file header, the checksum will no longer be valid. If you try to write the block at this time, you will not be successful. Use 'k' to fix the checksum (watch longword $05 to see it change), then use a 'U' to write the block. If you have hopelessly messed up the block, simply move to another block and come back _without_ using 'U'. The old contents of the block will not be altered until you type a 'U'. Now go back to the root block (by typing an 'r'), and invalidate the bitmap as outlined above, exit Sectorama, and use the DiskChange command to start the disk-validator. This will reclaim the blocks taken up by the file you got rid of. If it interests you, try exiting without invalidating the bitmap, test the directory structure by doing a DIR OPT A and then using INFO to check the number of used/free blocks. Then go in again and invalidate the bitmap and do the diskchange to see the disk-validator in action. Another INFO should confirm the recovery of blocks. > Also does anyone know if the new harddisk.device floating around on BBSs >(which was created to solve overscan problems?) will help prevent the >corruption problems I am having? The new hddisk.device fixed a problem with fasle read/write errors caused by DMA contention with overscan or multiple screens visible. I don't know if it caused corruption of disks, but it is possible that if you had a read error while reading a directory or bitmap block in the middle of a write, and if you cancelled the operation, or crashed the machine at that time, that something was left in a bad state on the disk. If this has sounded too simple to you, please forgive me. I have no way of knowing your level of expertise, and also feel that there may be many on the net who might benefit from a simple explanation. -larry -- The transistor is a curiosity, and will never amount to much. -- Mr. Stringer, Basic Electronic Instructor, RCAF, 1962. +--------------------------------------------------------------------+ | // Larry Phillips UUCP: lphillips@lpami.van-bc.UUCP | | \X/ or: {ihnp4!alberta!ubc-vision,uunet}!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 | +--------------------------------------------------------------------+