Mercurial > hg > Members > kono > nitros9-code
changeset 470:6e1cff14e8c4
Article about recovering from disk crash
| author | roug |
|---|---|
| date | Sat, 05 Oct 2002 16:08:53 +0000 |
| parents | 6b15b51ee3ba |
| children | ce6c1122bee6 |
| files | docs/articles/diskcrash.article |
| diffstat | 1 files changed, 483 insertions(+), 0 deletions(-) [+] |
line wrap: on
line diff
--- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/docs/articles/diskcrash.article Sat Oct 05 16:08:53 2002 +0000 @@ -0,0 +1,483 @@ +<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook V4.1//EN"> +<!-- The author has not been contacted about adding this article to the + documentation set. +--> +<article> +<articleinfo> +<author><firstname>Dave</><surname>Gantz</></author> +<title>Arrgh!!!!! My disk crashed, now what do I do?</title> +</articleinfo> +<para> +Fixing crashed disks or at least recovering data from crashed disks can +be a time consumming ordeal which is why the best recommendation is to +ALWAYS keep current backups or DON'T use the disk at all if it is your +only copy. However, crashed disks do not have to mean lost data if you +know how to go about recovering the data. +</para> +<para> +Thats what this article is all about and comes as a result of the +three crashed disks I've had this past week as well as Chris Spry's +current predicament. I have co-written one other article on this +topic, but that pertained more specifically to boot disk problems. +(See the OS9 Newletter, Volume III Issue 11B, November 30, 1992) +</para> +<para> +You'll be needing a few tools handy to follow along with this article +and if your planning to just practice for the eventuallity of a +crashed disk then for God sakes use a backup of something. +</para> +<para> +------------------------------Tool List-------------------------------- +</para> +<para> +OS9 Level II Manual, the big thick one that comes with the OS9 Level II +disks. +</para> +<para> +DED -- Copyright 1987 by Doug DeMartinis -- preferably the edition below +</para> +<screen width="80"> +Header for: dEd This edition has a patch made to it +Module size: $17A2 #6050 so that it will recognize and +Module CRC: $299A3F (Good) identify the Bit Allocation Map or +Hdr parity: $8F BAM for short. The BAM is also +Exec. off: $0665 #1637 sometimes called DAM or Disk +Data Size: $0316 #790 Allocation Map.... +Edition: $05 #5 +Ty/La At/Rv: $11 $82 Besides its the one I use. You could +Prog mod, 6809 obj, re-en, R/O also use Qtip, but displays will differ +</screen> +<para> +A screen dump utility of some sort would also come in handy for this +exercise in avoiding futility. See the end of this article for +suggested files and source(s). +</para> +<para> +Now to dive in there and rescue Data <Grin>......... +</para> +<para> + +The first thing will cover is the breakdown of Logical Sector Number +zero on any OS9 disk, as well as the invocation of DED. All numbers +with a preceding $ are in hexadecimal (base 16) and others will be +in decimal (base 10). +</para> +<para> +To invoke DED for this excercise type the following from any OS9 +prompt on any 80x24 or 80x25 text screen or graphics screen with +stdfonts merged. +</para> +<screen> +OS9: DED /Dx@ (where x = the drive number with the disk + to be worked on in it.) +</screen> +<note> +<para> +The @ in the above command allows us to open any disk just as +if it were a file by itself, thus allowing us to work with +any and all data the disk contains with the exception of +high density disks in most cases. +</para> +</note> +<para> +Here is an example of my LSN $00. Offsets (Relative Addresses) are +read as LSN+left most column+top row. See the ** in the last row? +This would be read as LSN or $00+column or $70+top row or $04 or a +total offset of $0074. If we were on sector 1 then it would be $0174. +The definitions of the important bytes follow the excerpt. Also see page +5-2 in the technical reference section of the OS9 Level II manual. +</para> +<screen width="80"> +------------------------------------------------------------------------ +LSN=$00 00 + + 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 2 4 6 8 A C E +00: 00 0B D0 12 01 7A 00 01 00 00 03 00 00 FF D4 E3 ..P..z....... Tc +10: 07 00 12 00 00 00 00 00 00 00 5D 03 08 10 2D 52 ..........]...-R +20: 69 42 42 53 20 43 6F 6D 6D 61 6E 64 73 20 44 69 iBBS Commands Di +30: 73 EB 00 00 00 00 00 00 00 00 00 00 00 00 00 01 sk.............. +40: 01 03 21 03 00 54 02 00 00 12 00 12 03 09 00 61 ..!..T.........a +50: 40 00 00 00 00 00 00 00 00 00 00 00 00 74 2D 00 @............t-. +60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +70: 00 00 00 00 ** 00 00 00 00 00 00 00 00 00 00 00 ................ + + + Relative Size +Name Address (Bytes) Use or Function Mine +---------------------------------------------------------------------- +DD.TOT $00 3 Number of sectors on disk. $000BD0 +DD.TKS $03 1 Track size in sectors. $12 +DD.MAP $04 2 Number of bytes in allocation map. $017A +DD.BIT $06 2 Number of sectors per cluster $0001 +DD.DIR $08 3 Starting Sector of of Root Dir $000003 +DD.OWN $0B 2 Owners ID number (usually 0) $0000 +DD.ATT $0D 1 Disk attributes $FF +DD.DSK $0E 2 Disk identification (internal use) $D4E3 +DD.FMT $10 1 Disk Format, bit mapped $07 +DD.SPT $11 2 Number of sectors per track $0012 +DD.RES $13 2 Reserved for future use $00 +DD.BT $15 3 Starting sector of bootstrap file $000000 +DD.BSZ $18 2 Size of bootstrap file $0000 +DD.DAT $1A 5 Date of creation (Y:M:D:H:M) $5D0308102D +DD.NAM $1F 32 Disk name, last char has MSB set see above +DD.OPT $3F Path descriptor options +</screen> +<para> +Probably the most important byte to us here are the bytes at offsets +$08, $09, and $0A which tell us where the root directory begins. +Speaking of which, that is our next stop in the CoCo Zone.... +</para> +<screen width="80"> + +LSN=$03 03 + + 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 2 4 6 8 A C E +00: BF 00 00 5D 04 1A 0D 0A 02 00 00 01 20 00 00 00 ?..]........ ... +10: 00 00 04 00 07 00 00 00 00 00 00 00 00 00 00 00 ................ +20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +</screen> +<para> +Well here we are exactly where LSN $00 said the root directory starts, +at LSN $000003. But where are the filenames, you ask? Well they +start on the next sector. +</para> +<para> +This sector is called a File Descriptor sector or FD for short. Every +file or directory on an OS9 disk has one of these. This is why you can't +store a true 360K worth of files and user data on a DSDD 40 track drive +for example. +</para> +<para> +For our purpose I'm going to skip the explanation of the first 16 bytes +and get on with what we need from this sector to start finding data. +</para> +<para> +Starting with offset $10 ($0310) is what is called a segment list. This +segment list tells OS9 where a file or directory on disk is located and +how many sectors that file or directory occupies. There are 48 of these +segments avaiable each being 5 bytes wide. For you programmers, think of +it as a two dimensional array such as: DIM segment(48,5). What this +means is that your file or directory can occupy space in 48 different +locations on disk if it is badly fragmented. +</para> +<para> +In this case mine only occupies one segment starting at LSN $0400 and +is 7 sectors in size. So guess where our trip through the OS9 disk +takes us next? If you said sector 4 or offset $0400 your right! +</para> +<screen width="80"> + +LSN=$04 04 + + 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 2 4 6 8 A C E +00: 2E AE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 ................ +20: AE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 ................ +40: 43 4D 44 D3 00 00 00 00 00 00 00 00 00 00 00 00 CMDS............ +50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0B ................ +60: 53 59 D3 00 00 00 00 00 00 00 00 00 00 00 00 00 SYS............. +70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 0A ................ +80: 72 69 62 62 73 2E 63 66 E7 00 00 00 00 00 00 00 ribbs.cfg....... +90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 2F .............../ +A0: 72 69 62 62 73 67 EF 00 00 00 00 00 00 00 00 00 ribbsgo......... +B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 AC ..............., +C0: 4D 45 4E 55 D3 00 00 00 00 00 00 00 00 00 00 00 MENUS........... +D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 42 ...............B +E0: 4C 4F 47 D3 00 00 00 00 00 00 00 00 00 00 00 00 LOGS............ +F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 09 A3 ...............# +</screen> +<para> +Well here we are, finally. The root directory. Again for our purposes +I'm going to skip the first 32 bytes of this sector. +</para> +<para> +Each entry for each file or directory is composed of 32 bytes. 29 of +them represent the file or directory name while the last 3 tell where +to find that individual files or directories FD is located on the disk. +Looking at this perhaps you can see the importance of having your +directory names in ALL UPPERCASE and your file names in all lowercase. +</para> +<para> +In this example I have 4 directories (CMDS, SYS, MENUS, and LOGS) and +two files (ribbs.cfg and ribbsgo). Lets start with a file, ribbsgo +in this case. +</para> +<para> +Its entry starts at offset $A0 ($04A0) and ends at $BF ($04BF). The +first 29 bytes as I said are for the file name, the last character of +which has its Most Significant Bit set to mark the end of the file +name. The last 3 bytes tell us where to find the FD for ribbsgo which +is $0002AC or $02AC since the Most Significant Byte is 0. +</para> +<para> +So this is where we are off to next, sector $02AC. +</para> +<screen width="80"> + +LSN=$2AC 684 + + 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 2 4 6 8 A C E +00: 0B 00 00 5D 04 19 0C 11 01 00 00 04 A5 5D 04 19 ...]........%].. +10: 00 02 AD 00 05 00 00 00 00 00 00 00 00 00 00 00 ..-............. +20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +</screen> +<para> +Ok here we are. This FD is very similar to the one we examined on our +way to the root directory. It contains all the same information and +takes on exactly the same format as the FD for the root directory except +that this time we are talking about a file and not a directory. +</para> +<para> +It tells us that our file, ribbsgo, begins at sector $0002AD or $02AD and +occupies 5 sectors. So that is where we will go next. For the purposes +I will only include the first and last sectors in this text as examples. +I forgot to mention that we have proceeded through pages 5-3, 5-4, and +most of 5-5 of the technical reference section at this point. +</para> +<screen width="80"> + +LSN=$2AD 685 + + 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 2 4 6 8 A C E +00: 6F 6E 65 72 72 20 67 6F 74 6F 20 66 61 74 61 6C onerr goto fatal +10: 65 72 72 6F 72 0D 63 64 20 2F 64 64 0D 63 78 20 error.cd /dd.cx +20: 2F 64 64 2F 63 6D 64 73 0D 76 61 72 2E 30 3D 22 /dd/cmds.var.0=" +30: 22 0D 64 69 73 70 6C 61 79 20 30 43 20 30 32 20 ".display 0C 02 +40: 33 34 20 32 32 20 31 42 20 33 32 20 30 33 20 30 34 22 1B 32 03 0 +50: 35 20 32 30 0D 65 63 68 6F 20 50 6C 65 61 73 65 5 20.echo Please +60: 20 49 6E 73 65 72 74 20 79 6F 75 72 20 4F 53 39 Insert your OS9 +70: 20 42 6F 6F 74 20 44 69 73 6B 20 69 6E 20 2F 44 Boot Disk in /D +80: 30 2E 0D 64 69 73 70 6C 61 79 20 30 32 20 34 45 0..display 02 4E +90: 20 32 45 20 31 42 20 32 32 20 30 31 20 31 41 20 2E 1B 22 01 1A +A0: 31 30 20 31 39 20 30 33 20 30 30 20 30 31 20 30 10 19 03 00 01 0 +B0: 31 20 30 32 20 32 36 20 32 32 0D 65 63 68 6F 20 1 02 26 22.echo +C0: 50 72 65 73 73 20 41 6E 79 20 4B 65 79 0D 76 61 Press Any Key.va +D0: 72 2E 30 0D 2A 6E 6F 6B 65 79 70 72 65 73 73 0D r.0.*nokeypress. +E0: 69 66 20 25 30 3D 22 22 0D 67 6F 74 6F 20 6E 6F if %0="".goto no +F0: 6B 65 79 70 72 65 73 73 0D 65 6E 64 69 66 0D 64 keypress.endif.d +</screen> +<para> +Well we made it! The actual file data. There are no special codes or +anything of that nature here to explain. Just the ASCII codes for the +contents of the ribbsgo script file. With program modules it would be +the hexadecial representations of the commands and variables and such +within the program. +</para> +<para> +As I said there are 5 consecutive sectors (or 1 segment) that this file +occupies but I will only include this and the last sector, because +everything in between is technically the same. +</para> +<screen width="80"> + +LSN=$2B1 689 + + 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 2 4 6 8 A C E +00: 6F 63 6D 64 73 0D 67 6F 74 6F 20 2B 65 78 69 74 ocmds.goto +exit +10: 0D 2A 66 61 74 61 6C 65 72 72 6F 72 0D 65 63 68 .*fatalerror.ech +20: 6F 20 45 72 72 6F 72 20 25 2A 20 69 6E 20 52 69 o Error %* in Ri +30: 42 42 53 47 6F 2E 20 20 46 69 78 20 61 6E 64 20 BBSGo. Fix and +40: 74 72 79 20 61 67 61 69 6E 0D 67 6F 74 6F 20 2B try again.goto + +50: 65 78 69 74 0D 2A 66 69 6E 69 73 68 75 70 0D 64 exit.*finishup.d +60: 69 73 70 6C 61 79 20 31 62 20 32 33 0D 72 69 62 isplay 1b 23.rib +70: 62 73 6D 61 69 6E 20 23 31 36 4B 20 3C 3E 3E 3E bsmain #16K <>>> +80: 2F 77 37 26 0D 2A 65 78 69 74 0D 64 69 73 70 6C /w7&.*exit.displ +90: 61 79 20 31 62 20 33 32 20 30 30 20 30 35 20 32 ay 1b 32 00 05 2 +A0: 31 20 30 43 0D 00 00 00 00 00 00 00 00 00 00 00 1 0C............ +B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ +</screen> +<para> +Ok this is the last sector of the ribbsgo file. The important thing +to mention here is that this file does not contain essential information +throughout the entire sector. The file ends with a carriage return +($0D) at offset $A4 or $355 taking into account for the sector we are on. +See all the $00's following that carriage return? We don't need them. +I'll explain how to get rid of them later, for now its enough for you to +know that there not needed. In some cases those extra bytes may contain +$E5's which is the value that OS9 writes to each sector when you format +a disk. +</para> +<para> +Now that you have a basic understanding of how an OS9 disk is put +together to become an effective storage medium we can go on and discuss +how we are gonna go about recovering data. +</para> +<screen> + + Up/Down Arrows Read & display Next/Previous sector + <CR> Clean up the screen display + * Restart + $ Fork a SHELL (Ctrl-BREAK to return) +* A Append displayed sector to output file +* C Close output file + D Diddle (adjust) file length + E Edit the displayed sector + F Find a byte or text string (BREAK aborts) + H Help screen (also use '?') + L Link to a module - List all modules +* N Next occurrence of byte(s) or string (Find) +* O Open a file for output (use with Append) + P Push current sector onto stack + Q Quit dEd - Exit to OS9 + R Remove and display a sector from stack +* S Skip to given sector (sector # in hex) + U Unlink from module + V Verify all modules in file + W Write the sector back to the disk + X eXpert mode toggle on/off + Z Zap (fill in) the sector displayed +</screen> +<para> +What you see above is the built in help from DED. The options we will +be using most often are the starred options above. +</para> +<para> +* S Skip to given sector (sector # in hex) +</para> +<para> +This option will let us skip to the sector(s) that we have identified +from the file desciptors (FD's) and will speed things up considerably. +</para> +<para> +* O Open a file for output (use with Append) +</para> +<para> +Once we have found the first sector of the data we wish to recover +we can use this option to open a path to another disk (or RAM disk) +on which we will store the recovered data. Since we will have to +do some editing on the recovered file a RAM disk is recommended. +</para> +<para> +* A Append displayed sector to output file +</para> +<para> +Once we have opened the destination file for the data we are trying +to recover this option will let us add the current sector to that +new file. You use this until you either reach the end of that +particular segment (Another FD will most likely be displayed at the +end of a segment or file) or the end of the file. +</para> +<screen> + + Up/Down Arrows Read & display Next/Previous sector + <CR> Clean up the screen display + * Restart + $ Fork a SHELL (Ctrl-BREAK to return) +* A Append displayed sector to output file +* C Close output file + D Diddle (adjust) file length + E Edit the displayed sector +* F Find a byte or text string (BREAK aborts) + H Help screen (also use '?') + L Link to a module - List all modules +* N Next occurrence of byte(s) or string (Find) +* O Open a file for output (use with Append) + P Push current sector onto stack + Q Quit dEd - Exit to OS9 + R Remove and display a sector from stack +* S Skip to given sector (sector # in hex) + U Unlink from module + V Verify all modules in file + W Write the sector back to the disk + X eXpert mode toggle on/off + Z Zap (fill in) the sector displayed +</screen> +<para> +------------------------------------------------------------------------- +* C Close output file +</para> +<para> +Now that we have recovered the data or file we must close the file before +doing anything else with it. +</para> +<para> +* F Find a byte or text string (BREAK aborts) +* N Next occurrence of byte(s) or string (Find) +</para> +<para> +If you know specific words or byte sequences to look for within the data +or file your trying to recover then these two are handy for locating +those words or sequences. +</para> +<para> +Well we've recovered a file or data. There is, if you recall, quite +likely some extra unwanted bytes. What do we do to get rid of them? +Thats easy, again using DED (and ident for program modules) we +diddle with the file length. Now you won't be dealing with real +sector numbers, just the relative sector offset from the beginning +of the file. In this case it will read LSN $00 thru $04 although +we may not actually be on sectors 0-4. +</para> +<para> + +At any rate you need to find the last relative sector of the file +probably using the arrow keys to scroll through it. When you reach +the last sector look and the LSN, left column number, and top row +number and determine the offset for the last byte (the carriage +return) and add 1. In this example that last byte will be at +$04A4 then add 1 giving us $04A5. +</para> +<para> +Hit D for Diddle with file length. It will tell you the old length +and ask for the new length. Type it in ($04A5 for this example) and +press enter. You will see the extra bytes disappear in front of you. +</para> +<para> +Now hit Q to quit and answer 'Y' and you have just recovered your first +file. Give yourself a pat on the back, get a cup of coffee and dig in +cause your gonna be dancin on the keyboard for several hours to +completely recover one DSDD disk. +</para> +<para> +It took me roughly 24 hours to recover all data from 3-3 1/2" 756K +floppies (I have mine formatted for 84 tracks double side rather than +the usual 80 tracks double side <Evil Grin>). +</para> +<para> +For some disks your directories will get trashed and there is little +one can do to recover the directories (that I know of) in which case +you will have to sit there with the arrow keys in DED identifying +FD's and locating the 'lost' files. This is what took me so long, +my directories got trashed. +</para> +<para> +This is, as I said, a time consumming method but I know of no program +that will do it for you. If I ever get some of my other programming +projects finished I intend to write something, but for now this +method will have to do. +</para> +<para> +Good luck recovering that lost data! +</para> +</article>