Path: utzoo!utgpu!water!watmath!clyde!att!mtunx!rutgers!njin!princeton!udel!rochester!cornell!batcomputer!itsgw!steinmetz!uunet!munnari!elecvax!geoffo
From: geoffo@elecvax.eecs.unsw.oz (Geoff Oakley)
Newsgroups: comp.sys.amiga
Subject: Re: A plea for bad block handling in the file system.
Summary: At least find the bad blocks (tracks)
Message-ID: <4072@elecvax.eecs.unsw.oz>
Date: 8 Jun 88 03:44:31 GMT
References: <2009@sugar.UUCP> <7144@swan.ulowell.edu> <2026@sugar.UUCP> <6180@well.UUCP> <410@jc3b21.UUCP>
Organization: EE and CS, Uni of NSW, Sydney, Australia
Lines: 31

In case this opinion has not yet been posted.

I am not particularly concerned about sophisticated bad block handling
for floppies, but I do want to know about bad block when it is still
possible to recover from errors.  This is at time of write, not two weeks
later when I try to read it (and it was my only backup). 

To this end, when I am copying disks I use a program that does a verify,
such as Tom Rokicki's DFC (thanks Tom), rather than diskcopy which
seems to write on regardless.

When copying files I am less happy.  It seems that copy does not do a 
read after write check, so if it is important I try to remember to copy 
the new file to nil: as a manual verify.

Now my own `bad block hadling plea'.
I would like anything that writes to disk to do a read after write test
(possibly optionally, but what cost safety).  Possibly this could be
done simply in trackdisk.device, is it not just spinning the disk round
once more?

I apologise to copy and/or trackdisk.device if this already happens,
but several lost backup files make me cautious.


Geoff Oakley           Telephone:
School of EE and CS    +61 2 697 4043
University of NSW      Network mail:
PO Box 1               ACSNet:  geoffo@elecvax.oz
Kensington NSW 2033    UUCP: {{uunet, hplabs, ubc-vision, mcvax, enea, ukc,
AUSTRALIA                     prlb2}!munnari, decvax!mulga}!elecvax.oz!geoffo