|
642
|
1 <?xml version="1.0" ?>
|
|
|
2 <!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.2//EN"
|
|
|
3 "http://www.oasis-open.org/docbook/xml/4.2/docbookx.dtd">
|
|
|
4 <!--
|
|
|
5 The author has not been contacted about adding this article to the
|
|
|
6 documentation set.
|
|
470
|
7 -->
|
|
|
8 <article>
|
|
|
9 <articleinfo>
|
|
642
|
10 <author><firstname>Dave</firstname><surname>Gantz</surname></author>
|
|
470
|
11 <title>Arrgh!!!!! My disk crashed, now what do I do?</title>
|
|
|
12 </articleinfo>
|
|
|
13 <para>
|
|
|
14 Fixing crashed disks or at least recovering data from crashed disks can
|
|
|
15 be a time consumming ordeal which is why the best recommendation is to
|
|
|
16 ALWAYS keep current backups or DON'T use the disk at all if it is your
|
|
|
17 only copy. However, crashed disks do not have to mean lost data if you
|
|
|
18 know how to go about recovering the data.
|
|
|
19 </para>
|
|
|
20 <para>
|
|
|
21 Thats what this article is all about and comes as a result of the
|
|
|
22 three crashed disks I've had this past week as well as Chris Spry's
|
|
|
23 current predicament. I have co-written one other article on this
|
|
|
24 topic, but that pertained more specifically to boot disk problems.
|
|
|
25 (See the OS9 Newletter, Volume III Issue 11B, November 30, 1992)
|
|
|
26 </para>
|
|
|
27 <para>
|
|
|
28 You'll be needing a few tools handy to follow along with this article
|
|
|
29 and if your planning to just practice for the eventuallity of a
|
|
|
30 crashed disk then for God sakes use a backup of something.
|
|
|
31 </para>
|
|
|
32 <para>
|
|
|
33 ------------------------------Tool List--------------------------------
|
|
|
34 </para>
|
|
|
35 <para>
|
|
|
36 OS9 Level II Manual, the big thick one that comes with the OS9 Level II
|
|
|
37 disks.
|
|
|
38 </para>
|
|
|
39 <para>
|
|
|
40 DED -- Copyright 1987 by Doug DeMartinis -- preferably the edition below
|
|
|
41 </para>
|
|
|
42 <screen width="80">
|
|
|
43 Header for: dEd This edition has a patch made to it
|
|
|
44 Module size: $17A2 #6050 so that it will recognize and
|
|
|
45 Module CRC: $299A3F (Good) identify the Bit Allocation Map or
|
|
|
46 Hdr parity: $8F BAM for short. The BAM is also
|
|
|
47 Exec. off: $0665 #1637 sometimes called DAM or Disk
|
|
|
48 Data Size: $0316 #790 Allocation Map....
|
|
|
49 Edition: $05 #5
|
|
|
50 Ty/La At/Rv: $11 $82 Besides its the one I use. You could
|
|
|
51 Prog mod, 6809 obj, re-en, R/O also use Qtip, but displays will differ
|
|
|
52 </screen>
|
|
|
53 <para>
|
|
|
54 A screen dump utility of some sort would also come in handy for this
|
|
|
55 exercise in avoiding futility. See the end of this article for
|
|
|
56 suggested files and source(s).
|
|
|
57 </para>
|
|
|
58 <para>
|
|
|
59 Now to dive in there and rescue Data <Grin>.........
|
|
|
60 </para>
|
|
|
61 <para>
|
|
|
62
|
|
|
63 The first thing will cover is the breakdown of Logical Sector Number
|
|
|
64 zero on any OS9 disk, as well as the invocation of DED. All numbers
|
|
|
65 with a preceding $ are in hexadecimal (base 16) and others will be
|
|
|
66 in decimal (base 10).
|
|
|
67 </para>
|
|
|
68 <para>
|
|
|
69 To invoke DED for this excercise type the following from any OS9
|
|
|
70 prompt on any 80x24 or 80x25 text screen or graphics screen with
|
|
|
71 stdfonts merged.
|
|
|
72 </para>
|
|
|
73 <screen>
|
|
|
74 OS9: DED /Dx@ (where x = the drive number with the disk
|
|
|
75 to be worked on in it.)
|
|
|
76 </screen>
|
|
|
77 <note>
|
|
|
78 <para>
|
|
|
79 The @ in the above command allows us to open any disk just as
|
|
|
80 if it were a file by itself, thus allowing us to work with
|
|
|
81 any and all data the disk contains with the exception of
|
|
|
82 high density disks in most cases.
|
|
|
83 </para>
|
|
|
84 </note>
|
|
|
85 <para>
|
|
|
86 Here is an example of my LSN $00. Offsets (Relative Addresses) are
|
|
|
87 read as LSN+left most column+top row. See the ** in the last row?
|
|
|
88 This would be read as LSN or $00+column or $70+top row or $04 or a
|
|
|
89 total offset of $0074. If we were on sector 1 then it would be $0174.
|
|
|
90 The definitions of the important bytes follow the excerpt. Also see page
|
|
|
91 5-2 in the technical reference section of the OS9 Level II manual.
|
|
|
92 </para>
|
|
|
93 <screen width="80">
|
|
|
94 ------------------------------------------------------------------------
|
|
|
95 LSN=$00 00
|
|
|
96
|
|
|
97 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 2 4 6 8 A C E
|
|
|
98 00: 00 0B D0 12 01 7A 00 01 00 00 03 00 00 FF D4 E3 ..P..z....... Tc
|
|
|
99 10: 07 00 12 00 00 00 00 00 00 00 5D 03 08 10 2D 52 ..........]...-R
|
|
|
100 20: 69 42 42 53 20 43 6F 6D 6D 61 6E 64 73 20 44 69 iBBS Commands Di
|
|
|
101 30: 73 EB 00 00 00 00 00 00 00 00 00 00 00 00 00 01 sk..............
|
|
|
102 40: 01 03 21 03 00 54 02 00 00 12 00 12 03 09 00 61 ..!..T.........a
|
|
|
103 50: 40 00 00 00 00 00 00 00 00 00 00 00 00 74 2D 00 @............t-.
|
|
|
104 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
105 70: 00 00 00 00 ** 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
106
|
|
|
107
|
|
|
108 Relative Size
|
|
|
109 Name Address (Bytes) Use or Function Mine
|
|
|
110 ----------------------------------------------------------------------
|
|
|
111 DD.TOT $00 3 Number of sectors on disk. $000BD0
|
|
|
112 DD.TKS $03 1 Track size in sectors. $12
|
|
|
113 DD.MAP $04 2 Number of bytes in allocation map. $017A
|
|
|
114 DD.BIT $06 2 Number of sectors per cluster $0001
|
|
|
115 DD.DIR $08 3 Starting Sector of of Root Dir $000003
|
|
|
116 DD.OWN $0B 2 Owners ID number (usually 0) $0000
|
|
|
117 DD.ATT $0D 1 Disk attributes $FF
|
|
|
118 DD.DSK $0E 2 Disk identification (internal use) $D4E3
|
|
|
119 DD.FMT $10 1 Disk Format, bit mapped $07
|
|
|
120 DD.SPT $11 2 Number of sectors per track $0012
|
|
|
121 DD.RES $13 2 Reserved for future use $00
|
|
|
122 DD.BT $15 3 Starting sector of bootstrap file $000000
|
|
|
123 DD.BSZ $18 2 Size of bootstrap file $0000
|
|
|
124 DD.DAT $1A 5 Date of creation (Y:M:D:H:M) $5D0308102D
|
|
|
125 DD.NAM $1F 32 Disk name, last char has MSB set see above
|
|
|
126 DD.OPT $3F Path descriptor options
|
|
|
127 </screen>
|
|
|
128 <para>
|
|
|
129 Probably the most important byte to us here are the bytes at offsets
|
|
|
130 $08, $09, and $0A which tell us where the root directory begins.
|
|
|
131 Speaking of which, that is our next stop in the CoCo Zone....
|
|
|
132 </para>
|
|
|
133 <screen width="80">
|
|
|
134
|
|
|
135 LSN=$03 03
|
|
|
136
|
|
|
137 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 2 4 6 8 A C E
|
|
|
138 00: BF 00 00 5D 04 1A 0D 0A 02 00 00 01 20 00 00 00 ?..]........ ...
|
|
|
139 10: 00 00 04 00 07 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
140 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
141 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
142 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
143 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
144 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
145 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
146 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
147 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
148 A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
149 B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
150 C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
151 D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
152 E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
153 F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
154 </screen>
|
|
|
155 <para>
|
|
|
156 Well here we are exactly where LSN $00 said the root directory starts,
|
|
|
157 at LSN $000003. But where are the filenames, you ask? Well they
|
|
|
158 start on the next sector.
|
|
|
159 </para>
|
|
|
160 <para>
|
|
|
161 This sector is called a File Descriptor sector or FD for short. Every
|
|
|
162 file or directory on an OS9 disk has one of these. This is why you can't
|
|
|
163 store a true 360K worth of files and user data on a DSDD 40 track drive
|
|
|
164 for example.
|
|
|
165 </para>
|
|
|
166 <para>
|
|
|
167 For our purpose I'm going to skip the explanation of the first 16 bytes
|
|
|
168 and get on with what we need from this sector to start finding data.
|
|
|
169 </para>
|
|
|
170 <para>
|
|
|
171 Starting with offset $10 ($0310) is what is called a segment list. This
|
|
|
172 segment list tells OS9 where a file or directory on disk is located and
|
|
|
173 how many sectors that file or directory occupies. There are 48 of these
|
|
|
174 segments avaiable each being 5 bytes wide. For you programmers, think of
|
|
|
175 it as a two dimensional array such as: DIM segment(48,5). What this
|
|
|
176 means is that your file or directory can occupy space in 48 different
|
|
|
177 locations on disk if it is badly fragmented.
|
|
|
178 </para>
|
|
|
179 <para>
|
|
|
180 In this case mine only occupies one segment starting at LSN $0400 and
|
|
|
181 is 7 sectors in size. So guess where our trip through the OS9 disk
|
|
|
182 takes us next? If you said sector 4 or offset $0400 your right!
|
|
|
183 </para>
|
|
|
184 <screen width="80">
|
|
|
185
|
|
|
186 LSN=$04 04
|
|
|
187
|
|
|
188 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 2 4 6 8 A C E
|
|
|
189 00: 2E AE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
190 10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 ................
|
|
|
191 20: AE 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
192 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 03 ................
|
|
|
193 40: 43 4D 44 D3 00 00 00 00 00 00 00 00 00 00 00 00 CMDS............
|
|
|
194 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 0B ................
|
|
|
195 60: 53 59 D3 00 00 00 00 00 00 00 00 00 00 00 00 00 SYS.............
|
|
|
196 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 0A ................
|
|
|
197 80: 72 69 62 62 73 2E 63 66 E7 00 00 00 00 00 00 00 ribbs.cfg.......
|
|
|
198 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 2F .............../
|
|
|
199 A0: 72 69 62 62 73 67 EF 00 00 00 00 00 00 00 00 00 ribbsgo.........
|
|
|
200 B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 AC ...............,
|
|
|
201 C0: 4D 45 4E 55 D3 00 00 00 00 00 00 00 00 00 00 00 MENUS...........
|
|
|
202 D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 07 42 ...............B
|
|
|
203 E0: 4C 4F 47 D3 00 00 00 00 00 00 00 00 00 00 00 00 LOGS............
|
|
|
204 F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 09 A3 ...............#
|
|
|
205 </screen>
|
|
|
206 <para>
|
|
|
207 Well here we are, finally. The root directory. Again for our purposes
|
|
|
208 I'm going to skip the first 32 bytes of this sector.
|
|
|
209 </para>
|
|
|
210 <para>
|
|
|
211 Each entry for each file or directory is composed of 32 bytes. 29 of
|
|
|
212 them represent the file or directory name while the last 3 tell where
|
|
|
213 to find that individual files or directories FD is located on the disk.
|
|
|
214 Looking at this perhaps you can see the importance of having your
|
|
|
215 directory names in ALL UPPERCASE and your file names in all lowercase.
|
|
|
216 </para>
|
|
|
217 <para>
|
|
|
218 In this example I have 4 directories (CMDS, SYS, MENUS, and LOGS) and
|
|
|
219 two files (ribbs.cfg and ribbsgo). Lets start with a file, ribbsgo
|
|
|
220 in this case.
|
|
|
221 </para>
|
|
|
222 <para>
|
|
|
223 Its entry starts at offset $A0 ($04A0) and ends at $BF ($04BF). The
|
|
|
224 first 29 bytes as I said are for the file name, the last character of
|
|
|
225 which has its Most Significant Bit set to mark the end of the file
|
|
|
226 name. The last 3 bytes tell us where to find the FD for ribbsgo which
|
|
|
227 is $0002AC or $02AC since the Most Significant Byte is 0.
|
|
|
228 </para>
|
|
|
229 <para>
|
|
|
230 So this is where we are off to next, sector $02AC.
|
|
|
231 </para>
|
|
|
232 <screen width="80">
|
|
|
233
|
|
|
234 LSN=$2AC 684
|
|
|
235
|
|
|
236 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 2 4 6 8 A C E
|
|
|
237 00: 0B 00 00 5D 04 19 0C 11 01 00 00 04 A5 5D 04 19 ...]........%]..
|
|
|
238 10: 00 02 AD 00 05 00 00 00 00 00 00 00 00 00 00 00 ..-.............
|
|
|
239 20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
240 30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
241 40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
242 50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
243 60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
244 70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
245 80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
246 90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
247 A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
248 B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
249 C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
250 D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
251 E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
252 F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
253 </screen>
|
|
|
254 <para>
|
|
|
255 Ok here we are. This FD is very similar to the one we examined on our
|
|
|
256 way to the root directory. It contains all the same information and
|
|
|
257 takes on exactly the same format as the FD for the root directory except
|
|
|
258 that this time we are talking about a file and not a directory.
|
|
|
259 </para>
|
|
|
260 <para>
|
|
|
261 It tells us that our file, ribbsgo, begins at sector $0002AD or $02AD and
|
|
|
262 occupies 5 sectors. So that is where we will go next. For the purposes
|
|
|
263 I will only include the first and last sectors in this text as examples.
|
|
|
264 I forgot to mention that we have proceeded through pages 5-3, 5-4, and
|
|
|
265 most of 5-5 of the technical reference section at this point.
|
|
|
266 </para>
|
|
|
267 <screen width="80">
|
|
|
268
|
|
|
269 LSN=$2AD 685
|
|
|
270
|
|
|
271 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 2 4 6 8 A C E
|
|
|
272 00: 6F 6E 65 72 72 20 67 6F 74 6F 20 66 61 74 61 6C onerr goto fatal
|
|
|
273 10: 65 72 72 6F 72 0D 63 64 20 2F 64 64 0D 63 78 20 error.cd /dd.cx
|
|
|
274 20: 2F 64 64 2F 63 6D 64 73 0D 76 61 72 2E 30 3D 22 /dd/cmds.var.0="
|
|
|
275 30: 22 0D 64 69 73 70 6C 61 79 20 30 43 20 30 32 20 ".display 0C 02
|
|
|
276 40: 33 34 20 32 32 20 31 42 20 33 32 20 30 33 20 30 34 22 1B 32 03 0
|
|
|
277 50: 35 20 32 30 0D 65 63 68 6F 20 50 6C 65 61 73 65 5 20.echo Please
|
|
|
278 60: 20 49 6E 73 65 72 74 20 79 6F 75 72 20 4F 53 39 Insert your OS9
|
|
|
279 70: 20 42 6F 6F 74 20 44 69 73 6B 20 69 6E 20 2F 44 Boot Disk in /D
|
|
|
280 80: 30 2E 0D 64 69 73 70 6C 61 79 20 30 32 20 34 45 0..display 02 4E
|
|
|
281 90: 20 32 45 20 31 42 20 32 32 20 30 31 20 31 41 20 2E 1B 22 01 1A
|
|
|
282 A0: 31 30 20 31 39 20 30 33 20 30 30 20 30 31 20 30 10 19 03 00 01 0
|
|
|
283 B0: 31 20 30 32 20 32 36 20 32 32 0D 65 63 68 6F 20 1 02 26 22.echo
|
|
|
284 C0: 50 72 65 73 73 20 41 6E 79 20 4B 65 79 0D 76 61 Press Any Key.va
|
|
|
285 D0: 72 2E 30 0D 2A 6E 6F 6B 65 79 70 72 65 73 73 0D r.0.*nokeypress.
|
|
|
286 E0: 69 66 20 25 30 3D 22 22 0D 67 6F 74 6F 20 6E 6F if %0="".goto no
|
|
|
287 F0: 6B 65 79 70 72 65 73 73 0D 65 6E 64 69 66 0D 64 keypress.endif.d
|
|
|
288 </screen>
|
|
|
289 <para>
|
|
|
290 Well we made it! The actual file data. There are no special codes or
|
|
|
291 anything of that nature here to explain. Just the ASCII codes for the
|
|
|
292 contents of the ribbsgo script file. With program modules it would be
|
|
|
293 the hexadecial representations of the commands and variables and such
|
|
|
294 within the program.
|
|
|
295 </para>
|
|
|
296 <para>
|
|
|
297 As I said there are 5 consecutive sectors (or 1 segment) that this file
|
|
|
298 occupies but I will only include this and the last sector, because
|
|
|
299 everything in between is technically the same.
|
|
|
300 </para>
|
|
|
301 <screen width="80">
|
|
|
302
|
|
|
303 LSN=$2B1 689
|
|
|
304
|
|
|
305 0 1 2 3 4 5 6 7 8 9 A B C D E F 0 2 4 6 8 A C E
|
|
|
306 00: 6F 63 6D 64 73 0D 67 6F 74 6F 20 2B 65 78 69 74 ocmds.goto +exit
|
|
|
307 10: 0D 2A 66 61 74 61 6C 65 72 72 6F 72 0D 65 63 68 .*fatalerror.ech
|
|
|
308 20: 6F 20 45 72 72 6F 72 20 25 2A 20 69 6E 20 52 69 o Error %* in Ri
|
|
|
309 30: 42 42 53 47 6F 2E 20 20 46 69 78 20 61 6E 64 20 BBSGo. Fix and
|
|
|
310 40: 74 72 79 20 61 67 61 69 6E 0D 67 6F 74 6F 20 2B try again.goto +
|
|
|
311 50: 65 78 69 74 0D 2A 66 69 6E 69 73 68 75 70 0D 64 exit.*finishup.d
|
|
|
312 60: 69 73 70 6C 61 79 20 31 62 20 32 33 0D 72 69 62 isplay 1b 23.rib
|
|
|
313 70: 62 73 6D 61 69 6E 20 23 31 36 4B 20 3C 3E 3E 3E bsmain #16K <>>>
|
|
|
314 80: 2F 77 37 26 0D 2A 65 78 69 74 0D 64 69 73 70 6C /w7&.*exit.displ
|
|
|
315 90: 61 79 20 31 62 20 33 32 20 30 30 20 30 35 20 32 ay 1b 32 00 05 2
|
|
|
316 A0: 31 20 30 43 0D 00 00 00 00 00 00 00 00 00 00 00 1 0C............
|
|
|
317 B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
318 C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
319 D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
320 E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
321 F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
|
|
|
322 </screen>
|
|
|
323 <para>
|
|
|
324 Ok this is the last sector of the ribbsgo file. The important thing
|
|
|
325 to mention here is that this file does not contain essential information
|
|
|
326 throughout the entire sector. The file ends with a carriage return
|
|
|
327 ($0D) at offset $A4 or $355 taking into account for the sector we are on.
|
|
|
328 See all the $00's following that carriage return? We don't need them.
|
|
|
329 I'll explain how to get rid of them later, for now its enough for you to
|
|
|
330 know that there not needed. In some cases those extra bytes may contain
|
|
|
331 $E5's which is the value that OS9 writes to each sector when you format
|
|
|
332 a disk.
|
|
|
333 </para>
|
|
|
334 <para>
|
|
|
335 Now that you have a basic understanding of how an OS9 disk is put
|
|
|
336 together to become an effective storage medium we can go on and discuss
|
|
|
337 how we are gonna go about recovering data.
|
|
|
338 </para>
|
|
|
339 <screen>
|
|
|
340
|
|
|
341 Up/Down Arrows Read & display Next/Previous sector
|
|
|
342 <CR> Clean up the screen display
|
|
|
343 * Restart
|
|
|
344 $ Fork a SHELL (Ctrl-BREAK to return)
|
|
|
345 * A Append displayed sector to output file
|
|
|
346 * C Close output file
|
|
|
347 D Diddle (adjust) file length
|
|
|
348 E Edit the displayed sector
|
|
|
349 F Find a byte or text string (BREAK aborts)
|
|
|
350 H Help screen (also use '?')
|
|
|
351 L Link to a module - List all modules
|
|
|
352 * N Next occurrence of byte(s) or string (Find)
|
|
|
353 * O Open a file for output (use with Append)
|
|
|
354 P Push current sector onto stack
|
|
|
355 Q Quit dEd - Exit to OS9
|
|
|
356 R Remove and display a sector from stack
|
|
|
357 * S Skip to given sector (sector # in hex)
|
|
|
358 U Unlink from module
|
|
|
359 V Verify all modules in file
|
|
|
360 W Write the sector back to the disk
|
|
|
361 X eXpert mode toggle on/off
|
|
|
362 Z Zap (fill in) the sector displayed
|
|
|
363 </screen>
|
|
|
364 <para>
|
|
|
365 What you see above is the built in help from DED. The options we will
|
|
|
366 be using most often are the starred options above.
|
|
|
367 </para>
|
|
|
368 <para>
|
|
|
369 * S Skip to given sector (sector # in hex)
|
|
|
370 </para>
|
|
|
371 <para>
|
|
|
372 This option will let us skip to the sector(s) that we have identified
|
|
|
373 from the file desciptors (FD's) and will speed things up considerably.
|
|
|
374 </para>
|
|
|
375 <para>
|
|
|
376 * O Open a file for output (use with Append)
|
|
|
377 </para>
|
|
|
378 <para>
|
|
|
379 Once we have found the first sector of the data we wish to recover
|
|
|
380 we can use this option to open a path to another disk (or RAM disk)
|
|
|
381 on which we will store the recovered data. Since we will have to
|
|
|
382 do some editing on the recovered file a RAM disk is recommended.
|
|
|
383 </para>
|
|
|
384 <para>
|
|
|
385 * A Append displayed sector to output file
|
|
|
386 </para>
|
|
|
387 <para>
|
|
|
388 Once we have opened the destination file for the data we are trying
|
|
|
389 to recover this option will let us add the current sector to that
|
|
|
390 new file. You use this until you either reach the end of that
|
|
|
391 particular segment (Another FD will most likely be displayed at the
|
|
|
392 end of a segment or file) or the end of the file.
|
|
|
393 </para>
|
|
|
394 <screen>
|
|
|
395
|
|
|
396 Up/Down Arrows Read & display Next/Previous sector
|
|
|
397 <CR> Clean up the screen display
|
|
|
398 * Restart
|
|
|
399 $ Fork a SHELL (Ctrl-BREAK to return)
|
|
|
400 * A Append displayed sector to output file
|
|
|
401 * C Close output file
|
|
|
402 D Diddle (adjust) file length
|
|
|
403 E Edit the displayed sector
|
|
|
404 * F Find a byte or text string (BREAK aborts)
|
|
|
405 H Help screen (also use '?')
|
|
|
406 L Link to a module - List all modules
|
|
|
407 * N Next occurrence of byte(s) or string (Find)
|
|
|
408 * O Open a file for output (use with Append)
|
|
|
409 P Push current sector onto stack
|
|
|
410 Q Quit dEd - Exit to OS9
|
|
|
411 R Remove and display a sector from stack
|
|
|
412 * S Skip to given sector (sector # in hex)
|
|
|
413 U Unlink from module
|
|
|
414 V Verify all modules in file
|
|
|
415 W Write the sector back to the disk
|
|
|
416 X eXpert mode toggle on/off
|
|
|
417 Z Zap (fill in) the sector displayed
|
|
471
|
418 -------------------------------------------------------------------------
|
|
470
|
419 </screen>
|
|
|
420 <para>
|
|
|
421 * C Close output file
|
|
|
422 </para>
|
|
|
423 <para>
|
|
|
424 Now that we have recovered the data or file we must close the file before
|
|
|
425 doing anything else with it.
|
|
|
426 </para>
|
|
|
427 <para>
|
|
|
428 * F Find a byte or text string (BREAK aborts)
|
|
471
|
429 </para>
|
|
|
430 <para>
|
|
470
|
431 * N Next occurrence of byte(s) or string (Find)
|
|
|
432 </para>
|
|
|
433 <para>
|
|
|
434 If you know specific words or byte sequences to look for within the data
|
|
|
435 or file your trying to recover then these two are handy for locating
|
|
|
436 those words or sequences.
|
|
|
437 </para>
|
|
|
438 <para>
|
|
|
439 Well we've recovered a file or data. There is, if you recall, quite
|
|
|
440 likely some extra unwanted bytes. What do we do to get rid of them?
|
|
|
441 Thats easy, again using DED (and ident for program modules) we
|
|
|
442 diddle with the file length. Now you won't be dealing with real
|
|
|
443 sector numbers, just the relative sector offset from the beginning
|
|
|
444 of the file. In this case it will read LSN $00 thru $04 although
|
|
|
445 we may not actually be on sectors 0-4.
|
|
|
446 </para>
|
|
|
447 <para>
|
|
|
448 At any rate you need to find the last relative sector of the file
|
|
|
449 probably using the arrow keys to scroll through it. When you reach
|
|
|
450 the last sector look and the LSN, left column number, and top row
|
|
|
451 number and determine the offset for the last byte (the carriage
|
|
|
452 return) and add 1. In this example that last byte will be at
|
|
|
453 $04A4 then add 1 giving us $04A5.
|
|
|
454 </para>
|
|
|
455 <para>
|
|
|
456 Hit D for Diddle with file length. It will tell you the old length
|
|
|
457 and ask for the new length. Type it in ($04A5 for this example) and
|
|
|
458 press enter. You will see the extra bytes disappear in front of you.
|
|
|
459 </para>
|
|
|
460 <para>
|
|
|
461 Now hit Q to quit and answer 'Y' and you have just recovered your first
|
|
|
462 file. Give yourself a pat on the back, get a cup of coffee and dig in
|
|
|
463 cause your gonna be dancin on the keyboard for several hours to
|
|
|
464 completely recover one DSDD disk.
|
|
|
465 </para>
|
|
|
466 <para>
|
|
|
467 It took me roughly 24 hours to recover all data from 3-3 1/2" 756K
|
|
|
468 floppies (I have mine formatted for 84 tracks double side rather than
|
|
|
469 the usual 80 tracks double side <Evil Grin>).
|
|
|
470 </para>
|
|
|
471 <para>
|
|
|
472 For some disks your directories will get trashed and there is little
|
|
|
473 one can do to recover the directories (that I know of) in which case
|
|
|
474 you will have to sit there with the arrow keys in DED identifying
|
|
|
475 FD's and locating the 'lost' files. This is what took me so long,
|
|
|
476 my directories got trashed.
|
|
|
477 </para>
|
|
|
478 <para>
|
|
|
479 This is, as I said, a time consumming method but I know of no program
|
|
|
480 that will do it for you. If I ever get some of my other programming
|
|
|
481 projects finished I intend to write something, but for now this
|
|
|
482 method will have to do.
|
|
|
483 </para>
|
|
|
484 <para>
|
|
|
485 Good luck recovering that lost data!
|
|
|
486 </para>
|
|
|
487 </article>
|
