Date: Thu, 10 May 2001 22:35:59 +0200 From: J Wunsch <j@uriah.heep.sax.de> To: "Julian Stacey Jhs@jhs.muc.de" <jhs@jhs.muc.de> Cc: "Brian W. Buchanan" <brian@CSUA.Berkeley.EDU>, hackers@FreeBSD.ORG Subject: Re: fd driver hacking to recover data Message-ID: <20010510223559.B46010@uriah.heep.sax.de> In-Reply-To: <200105101651.f4AGpMh58396@jhs.muc.de>; from jhs@jhs.muc.de on Thu, May 10, 2001 at 06:51:22PM %2B0200 References: <brian@CSUA.Berkeley.EDU> <200105101651.f4AGpMh58396@jhs.muc.de>
next in thread | previous in thread | raw e-mail | index | archive | help
As Julian Stacey Jhs@jhs.muc.de wrote: >> fd0c: hard error reading fsbn 0 of 0-31 (ST0 40<abnrml> ST1 1<no_am> ST2 0 >> cyl 0 hd 0 sec 1) >> fd0c: hard error reading fsbn 1503 of 1488-1503 (ST0 44<abnrml,top_head> >> ST1 20<bad_crc> ST2 20<bad_crc> cyl 41 hd 1 sec 10) For this kind of errors, it's hard to recover. The first one is a `no address mark', i. e. the synchronization field for the very first sector hasn't been found at all until the index hole passed by a second time. This means the floppy is hosed, i doubt you would be able to recover anything even at bit-level. I think even the READ TRACK command of the FDC would fail in that case, since it tries to synchronize to the first address mark of each track first (and then returns the stream of bits starting at that point, up to the index hole). The second one isn't all that much better either. Since both ST1 and ST2 display the `bad_crc', it means it's a CRC error in the address mark field already, thus the beginning of this sector hasn't been found. If only one of those messages were there, it would be a CRC error in the data field instead, so the address mark had been recognized, but the data are corrupted. In that case (and only in that case), the FDC actually does transfer the data to the kernel buffer, and it might be possible to somehow transfer it to the userland program as well. >> Since the files on the disks are just text, all I want to do is to >> be able to extract as many of the bits on the disk as possible, >> even if some of the bits are wrong, and then run strings over it >> and sort out the content. Btw. (don't know whether that's news to you), dd if=/dev/fd0 of=savefile conv=noerror,sync would prevent dd from stopping at the first error, and insert a block full of null bytes for all bad sectors. Note however that it'll be dog slow, since one read(2) is being issued for each sector by itself, which will almost guarantee to lose one floppy revolution until the next sector can be read. (Normally, when handling a floppy, you could increase the block size to something larger, e. g. bs=18k to issue one read(2) for an entire cylinder, but for conv=error, it would then declare the entire cylinder's worth of data to be in error, and discard them.) > I have a program that will rescue your data ! I seriously doubt it will recover the floppy with the dead address marks. ;-) > I have no idea if the FreeBSD ports DOS emulators allow access to floppy > hardware or not ? Nope. > - or modify the FreeBSD fd driver to pass the buffer on error. See above, it would only help at all in the (not so frequent) case of a CRC error in the data field. In all cases of an error in the address mark detection, the FDC doesn't return errored data either. > In 1987 with DOS I was lucky, ... In 1987, you had 5.25" floppies however. ;-) I can still read all of them today, while all the 3.5" crap fails within way shorter intervals, and thus probably also fails more frequently with address mark errors. -- cheers, J"org .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/ NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010510223559.B46010>