Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!bellcore!decvax!decwrl!glacier!Shasta!gus
From: gus@Shasta.UUCP
Newsgroups: net.micro.mac
Subject: Re: macintosh file system and disk layout questions.
Message-ID: <478@Shasta.ARPA>
Date: Fri, 2-May-86 03:32:22 EDT
Article-I.D.: Shasta.478
Posted: Fri May  2 03:32:22 1986
Date-Received: Sat, 3-May-86 20:08:15 EDT
References: <429@geowhiz.UUCP>
Distribution: net
Organization: Stanford University
Lines: 59

> *** REPLACE THIS LINE WITH YOUR MESSAGE ***
> 	I just spent (too much) time trying with the help of FEdit
> to fix up a disk.  The FEdit documentation, which until this
> time I had not bothered to download proved to be a wealth of
> information.  Good reading.  However when trying to muck about
> I ran across some "bad" sectors.  When FEdit (Resedit wont read 
> it either) tried to read them it said something about file errors 
> and told me it couldt find the requested sector on the track. ???? 
> Wow, I thought what gives.
> The file in question was the Clipboard file should be free of any 
> nasty protection schemes thought I,  well following the documentation I 
> looked in the directory sectors and traced all the blocks in the volume
> table etc... everything looked fine.  My question then is who tells
> what where these things are,  where are the bytes that tell whoever needs
> to know a sector is trashed, does that mean its trashed physically 
> ie the hardware cant read it?  Can it be fixed.  
> What could possably be on a disk that could not be read by the head, 
> even if it is garbage?  How can a disk drive just go and loose a 
> sector like that, fine father it is.
> 
> Thanks in advance for any help
> dave schuh
> !uwvax!geokwhiz!schuh
> 
> 
> PS by way of confession I had done some mucking with the directory blocks
> before I discovered the unreadable sectors, but I changed things back.
> I dont know for sure whether they were there before or not.

FEDIT works at the "sector" level. This means that it treats the disk as a
set of randomly accessible 512 byte blocks. Each block maps to a sector on
the disk. There are 8,9,10,11,or 12 sectors per track on a 400K disk. On an
800K disk "tracks" become heads/cylenders where a cylinder includes both
sides of the disk (heads) at the same radial distance from the center. 

Below the block level is the "nibble" level which is the lowest level
accessible from software and is the level at which "bit" copiers work. Each
sector contains two parts - a (short) address mark and a (long) data mark.
Address marks are used primarily to determine which sector on a particular
track is about to be read or written. These marks are written only by the
disk initialization routine. To access a sector, the disk driver first seeks
to the appropriate track, (on an 800K disk) sets the desired head, and starts
reading until it finds a sector mark. If this mark defines the appropriate
sector, then the data block directly following it is read (or written).

Read errors may occur anywhere on the disk, either on an address or on a data
mark. If it lands on a data mark, then that sector will not be readable, but
should be writable unless the media is damaged. If it lands at an address
mark, then the disk driver will never be able to find the sector, and it is
thus not readable, even though the data is valid.

The only program currently available which can deal at this level is MacZap.
This is a real hacker's tool. (and not too professionally put together!) 
To be used effectively, you really need to know exactly what is going on
inside a priori. Otherwise, you will likely make things worse. I have seen no
program which tries to automatically repair errors below the sector level 
generally because since address marks are much smaller than data marks, there
is little chance that a read error only hit the (repairable) address marks,
and not the data mark which contains the real data.