Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!tut.cis.ohio-state.edu!bloom-beacon!bu-cs!purdue!i.cc.purdue.edu!j.cc.purdue.edu!pur-ee!pur-phy!tlm
From: tlm@pur-phy (Timothy Lee Meisenheimer)
Newsgroups: comp.sys.amiga
Subject: Re: A plea for bad block handling in the file system.
Message-ID: <1184@pur-phy>
Date: 10 Jun 88 00:10:54 GMT
References: <2009@sugar.UUCP> <7144@swan.ulowell.edu> <2026@sugar.UUCP> <6180@well.UUCP> <410@jc3b21.UUCP> <2800@umd5.umd.edu> <2268@antique.UUCP>
Reply-To: tlm@newton.physics.purdue.edu.UUCP (Timothy Lee Meisenheimer)
Organization: Purdue Univ. Physics Dept., W. Lafayette, IN
Lines: 6

In article <2268@antique.UUCP> vax135!cjp (Charles Poirier) writes:
>Fixing a gaping hole in data security is plenty productive.
>Besides, this seems like a relatively easy thing to program.
Hey, couldn't we just mark all the disks in that bad track as
allocated but not to anything in particular? I'm not sure what would
happen when you did a diskcopy - probably just leave you with a
useless track.