Mercurial > hg > Members > kono > nitros9-code

comparison docs/articles/diskcrash.article @ 470:6e1cff14e8c4

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