Mercurial > hg > Members > kono > nitros9-code
view docs/articles/diskcrash.article @ 3051:d0ec54ac8b94
Added help files for sdir and sdrive
| author | tlindner |
|---|---|
| date | Sun, 25 Jan 2015 12:05:20 -0800 |
| parents | 1e04ad1dfdce |
| children |
line wrap: on
line source
<!-- The author has not been contacted about adding this article to the documentation set. --> <article> <articleinfo> <author><firstname>Dave</firstname><surname>Gantz</surname></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) </para> <para> * 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>