lphillips@lpami.wimsey.bc.ca (Larry Phillips) (09/16/89)
In <4354@ncar.ucar.edu>, hull@hao.ucar.edu (Howard Hull) writes: >search item, and filled in the name "OP22PB16C" in the string requester. When >I supplied the <CR> it searched for and apparently found a block containing >that string. But when I examined the specified block, it was a data block for >some other (old) file, and it did not contain the search string. So I then >tried a search on OP22PB16C.hpgl - which it also found. >Again, examination of the block revealed a data block from another file. But >since OP22PB16C.hpgl was intact in the file system, I was able to walk the >chain to the header; the header key thus located was different from the one >disclosed by the search. However, so I thought - by calculating the offset >between what the search reported and what direct examination disclosed, I >might perhaps apply this same offset to the search key and locate the block >with the OP22PB16C string. Sectorama has trouble with partitioned disks in a few areas, most notably the SEARCH area. It will find the block, but tell you the block number as counted from the first block on the physical disk. To find the actual block, subtract the number of blocks in the first partition(s). An earlier version of Sectorama had problems writing to a partitioned disk too, which was much more serious, and caused me no end of grief. >Then the fun began. Since the OP22PB16C file had been purged, there was no >entry for it in the directory hash chain. But sectorama seemed to have no >way to enter a base key other than to modify a block word. You can do this a couple of ways. One is to click on the block number in the lower right area where it shows the sector, track, block, and so on, and to enter the block number there. Unfortunately, this is decimal only. To enter hex, (as you correctly surmised), use the 'e' command and enter the hex number in any handy longword, hit <return> or <ESC> to get out of edit mode, then put the highlight back onto that same longword and hit the 'j'. If you don't use the 'k' and 'U', the block will not be written out to disk. >I was then able to D my way down the data block link, but I came up against >pretty much what disksalv had reported. This was obviously an old file systemn partition, since the FFS does not carry the data block links along with it. This becomes important later in this posting. > Fourteen blocks into the file, >there were three blocks that had been seriously re-written (described as >"corrupt block") but I was able to locate the remaining blocks of the file >(they were sequential). The damaged blocks looked for all the world like >bitmap blocks. [Question - will AmigaDOS write new bitmap blocks on top of >freshly purged file data blocks, even though there's still 12 megabytes of >fresh-formatted blocks in the partition? Wheeeeeeoooo!] Yes it will, _IF_ it is an OFS partition. FFS does not do this, thankfully. It seems like under OFS, the bitmaps get written on the first available block, and after a 'delete' that is often a block on which the file used to reside, and can even be the file header block. This really clenched my jaw while working on an undelete program. After discovering >this situation, I decided to fake it by patching the first six words of each >of the three munged blocks to restore the data link chain. This all seemed >to work out ok (sectorama could now follow the chain with repeated D commands). > >Thus encouraged, I proceeded to patch the directory hash chain (now in the >proper place and way), set all other modified directory words back to zero >so that AmigaDOS wouldn't choke and could now find the re-linked file. Not sure what you did here, but all that is necessary to patch the file header back into the proper place is to go to the parent directory and use the 'h' command to find where its entry should be. If the hash table is already in use, you can 'run down the hash chain' and add it in. For OFS, it can go onto the end of the chain, and in FFS, it should go in order of increasing block number, meaning that you have to point one hash chain entry at the file in question, and point the entry in the file to the next entry. >I corrected the directory checksum with the K command, and then pressed the >upper case U to get sectorama to update the block. The disk light reassuringly >flashed. Next I cleared the BMVALID flag in the root directory, fixed its >checksum, updated it, (got another disk LED flash) then I selected the close >gadget and got a good exit without any irregularities. AmigaDOS, of course, >called the validator. But when I asked for the dir, AmigaDOS did not find the >file. So I went back to sectorama for another look. Incredibly, the same >blocks I KNOW were modified (I saw the disk light flash when I hit "U", right?) >were the same as before the edit! Two possibilities... an older version of Sectorama might have written it to the wrong place, or you may not have used the 'k' command to correct the checksum. This is a failing in both versions of Sectorama, in that it will not write a block with a bad checksum. Since doing a checksum on a bitmap block will clobber it (bitmap blocks have the checksum in longword 0), you cannot manually change bitmap blocks. >So I ran disksalv again on the partition, and disksalv reported that indeed, >stuff WAS changed (lots of comment - conflicts, etc). I then figured that >sectorama wrote the modified data to some other blocks than the place >where it got them, or it wrote a whole sector (rather than just a block) >and that sector likely contained some blocks I munged (by entering search >keys in blank words, but not invoking U or K before the J to another block - >though if that were the case, I should have gotten some checksum errors, >shouldn't I?). Right... the use of the data areas to search for blocks with the 'j' command would not have caused any problem. As mentioned above, you may not have written some of the things you thought you did, due to the inability of Sectorama to write blocks with bad checksums. Oh, and blocks are equal to sectors. > [...] So I wonder - does sectorama have trouble with >SCSI disks (the aforementioned offset value was about the same as the number >of blocks in my first (boot) partition) so that it gets lost on read/write >arithmetic? No, it does have trouble with partitioned disks, more or less serious, depending on the version you have, and with unchecksummed sectors. > What is the current rev number for sectorama, anybody know? I have 1.1, and as far as I know, it has not progressed beyond that. The author (David Joiner) has been quite busy, and hasn't the time to upgrade it. A shame, really, because other than these few problems, it is a very good tool. I once asked if he would release source under non-disclosure or otherwise, and he declined. Perhaps someone he knows well could persuade him. >Thanks in advance y'know... Ypu're quite welcome... good luck on any future problems. -larry -- The Mac? Oh, that's just like a computer, only slower. +-----------------------------------------------------------------------+ | // Larry Phillips | | \X/ lphillips@lpami.wimsey.bc.ca -or- uunet!van-bc!lpami!lphillips | | COMPUSERVE: 76703,4322 -or- 76703.4322@compuserve.com | +-----------------------------------------------------------------------+
hull@hao.ucar.edu (Howard Hull) (09/16/89)
Gee, if there are a bunch of you having problems with the 40s, maybe you all ought to call Quantum at once :-) In Article 29435 of comp.sys.amiga dated 20 Dec 88 03:08:41, Marco Papa 'Doc' says: "Quantum can be reached at (408)-432-1100." Of course, by now that could have changed, so your mileage may vary. My 80s is cranking right along (9 months now) with daily turn on/off as part of the routine. I could mention, though, that last Thursday I for the first time screwed up (not my first mistake, just the first one on the 80s) and inadvertently deleted the wrong file (I was after OP22PB16C.hpgl and got OP22PB16C). It was ten days since the last backup. Friday would have been backup day. I had done a buncha stuff to it as of last Tuesday. I looked through my collection of PD undelete tools, but everything was for DF0. I ran disksalv on it, but disksalv recovered only 3300 bytes from 40000+. Since it was an AmigaDOS partition, I figured it should be duck soup, so I uudecoded a copy of sectorama from a net posting. I had a hard time at first trying to use the program, as the documentation is somewhat sparse. However, after some fussing around I found it fairly straightforward. I found that I could select any hexword in the screen for a given block, type the appropriate key for the function I wanted (i.e., J to jump to the header block with the key number selected on the page, C to follow the hash chain, D to get the first and subsequent data blocks after the header, H to return to the header from any data block, R to get back to the root block, etc). I used the menu to open the search item, and filled in the name "OP22PB16C" in the string requester. When I supplied the <CR> it searched for and apparently found a block containing that string. But when I examined the specified block, it was a data block for some other (old) file, and it did not contain the search string. So I then tried a search on OP22PB16C.hpgl - which it also found. Again, examination of the block revealed a data block from another file. But since OP22PB16C.hpgl was intact in the file system, I was able to walk the chain to the header; the header key thus located was different from the one disclosed by the search. However, so I thought - by calculating the offset between what the search reported and what direct examination disclosed, I might perhaps apply this same offset to the search key and locate the block with the OP22PB16C string. Then the fun began. Since the OP22PB16C file had been purged, there was no entry for it in the directory hash chain. But sectorama seemed to have no way to enter a base key other than to modify a block word. I needed to fake an entry in order to use the J command to examine the block. So I simply picked a blank word in the directory block, entered the header address after invoking the E command, then bailed out with escape so I could J to the block. Believe it or not, this procured the block with the much sought string! I was then able to D my way down the data block link, but I came up against pretty much what disksalv had reported. Fourteen blocks into the file, there were three blocks that had been seriously re-written (described as "corrupt block") but I was able to locate the remaining blocks of the file (they were sequential). The damaged blocks looked for all the world like bitmap blocks. [Question - will AmigaDOS write new bitmap blocks on top of freshly purged file data blocks, even though there's still 12 megabytes of fresh-formatted blocks in the partition? Wheeeeeeoooo!] After discovering this situation, I decided to fake it by patching the first six words of each of the three munged blocks to restore the data link chain. This all seemed to work out ok (sectorama could now follow the chain with repeated D commands). Thus encouraged, I proceeded to patch the directory hash chain (now in the proper place and way), set all other modified directory words back to zero so that AmigaDOS wouldn't choke and could now find the re-linked file. I corrected the directory checksum with the K command, and then pressed the upper case U to get sectorama to update the block. The disk light reassuringly flashed. Next I cleared the BMVALID flag in the root directory, fixed its checksum, updated it, (got another disk LED flash) then I selected the close gadget and got a good exit without any irregularities. AmigaDOS, of course, called the validator. But when I asked for the dir, AmigaDOS did not find the file. So I went back to sectorama for another look. Incredibly, the same blocks I KNOW were modified (I saw the disk light flash when I hit "U", right?) were the same as before the edit! So I ran disksalv again on the partition, and disksalv reported that indeed, stuff WAS changed (lots of comment - conflicts, etc). I then figured that sectorama wrote the modified data to some other blocks than the place where it got them, or it wrote a whole sector (rather than just a block) and that sector likely contained some blocks I munged (by entering search keys in blank words, but not invoking U or K before the J to another block - though if that were the case, I should have gotten some checksum errors, shouldn't I?). The file system thus hosed, I was forced to abandon the recovery of the file [surely a matter of efficiency, and not any particular lack of skill on my part, right? :-) ], re-format the partition and recover from a ten-day old backup. So I wonder - does sectorama have trouble with SCSI disks (the aforementioned offset value was about the same as the number of blocks in my first (boot) partition) so that it gets lost on read/write arithmetic? What is the current rev number for sectorama, anybody know? Thanks in advance y'know... Howard Hull hull@hao.ucar.edu
hull@hao.ucar.edu (Howard Hull) (09/18/89)
In article <764@lpami.wimsey.bc.ca> lphillips@lpami.wimsey.bc.ca (Larry Phillips) writes: >Sectorama has trouble with partitioned disks in a few areas, most notably the >SEARCH area. It will find the block, but tell you the block number as counted >from the first block on the physical disk. To find the actual block, subtract >the number of blocks in the first partition(s). An earlier version of Sectorama >had problems writing to a partitioned disk too, which was much more serious, >and caused me no end of grief. YAHOO #1. As this fits the description of my first problem exactly, it would appear that I have the "earlier version" (I have v02i029 posted to c.b.a by Craig Norborberg) - there is no mention of a version number in the docs... I surmise that this must be the same as the version on Fred Fish disk 102. I see by the Fish Index that there is another one one disk 119. As I have the entire Fish collection, I'll copy over the new one when I get home and add it to my "Dont Panic" disk. Maybe I can patch it. Thanks for the information on how to enter base keys. I think the earlier version of sectorama has the decimal field in a zone near the top of the frame, and that the decimal number is referenced to the 0th partition, as well. Time to get out the HP16C... >> [Question - will AmigaDOS write new bitmap blocks on top of >>freshly purged file data blocks, even though there's still 12 megabytes of >>fresh-formatted blocks in the partition? Wheeeeeeoooo!] > >Yes it will, _IF_ it is an OFS partition. FFS does not do this, thankfully. YAHOO #2. Righto, It was an OFS partition, and was so precisely so that I could follow data link chains, given I became so inspired by the situation... >>Thus encouraged, I proceeded to patch the directory hash chain (now in the >>proper place and way), set all other modified directory words back to zero >>so that AmigaDOS wouldn't choke and could now find the re-linked file. > >Not sure what you did here, but all that is necessary to patch the file header >back into the proper place is to go to the parent directory and use the 'h' >command to find where its entry should be. If the hash table is already in use, >you can 'run down the hash chain' and add it in. For OFS, it can go onto the >end of the chain, and in FFS, it should go in order of increasing block number, >meaning that you have to point one hash chain entry at the file in question, >and point the entry in the file to the next entry. AH. I didn't know this interesting little fact about FFS hash chains, but then I don't use FFS much (I mostly use drafting programs on my A2000 at work, and with them, an A2620 and a program coded for an MC68881/2 floating point chip is much more useful than a fast file system). >>blocks I KNOW were modified (I saw the disk light flash when I hit "U", right?) >>were the same as before the edit! > >Two possibilities... an older version of Sectorama might have written it to the >wrong place, BINGO... or you may not have used the 'k' command to correct the checksum. >This is a failing in both versions of Sectorama, in that it will not write a >block with a bad checksum. Since doing a checksum on a bitmap block will >clobber it (bitmap blocks have the checksum in longword 0), you cannot manually >change bitmap blocks. YAHOO #3. Sure enough, they _WERE_ bitmaps, then. Arrrrgh. >...Oh, and blocks are equal to sectors. Uh, I think I meant to say a "track" (or "cylinder") per write Update, perhaps. >No, it does have trouble with partitioned disks, more or less serious, >depending on the version you have, and with unchecksummed sectors. Ummm. Such a pitty. It was just the sort of tool I needed. One of the backup program vendors should write a tool like this and include it with their package under the heading of "Emergencia, emergencia, everyone is to be taken from sector..." >> What is the current rev number for sectorama, anybody know? > >I have 1.1, and as far as I know, it has not progressed beyond that. ... David Joiner should be encouraged to licence the source to Central Coast Software - I'll bet they'd distribute it. I have Quarterback, and it works just great. Beyond that, I just noticed that I have something in my PD collection called "DiskX V2.0", by Steve Tibbett. I just looked at the docs, and it says that it can handle anything that AmigaDOS thinks is a device, including hard disks. If anyone knows about a newer version of DiskX, or if there are significant bugs, post a note or drop some email this way. After I get through posting this I'll try it out on my now very recently backed up hard disk. So if there are bugs, it'll be too late by the time I see the posted or emailed reports, but then, what the hey... > >>Thanks in advance y'know... >Ypu're quite welcome... good luck on any future problems. Hey, yeah, great, rentrant, even. What a nice net reply you put together. > >| // Larry Phillips | Thanks much from yours truly, Howard Hull hull@hao.ucar.edu