schuh@geowhiz.UUCP (04/28/86)
*** 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 accross 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.
schuh@geowhiz.UUCP (04/28/86)
OOps my address was wrong in the previous message. Im at !uwvax!geowhiz!schuh not geokwhiz. thanks dave !uwvax!geowhiz!schuh
wert@Navajo.UUCP (05/01/86)
On almost any disk drive ever used, there are these things called address marks and data marks. The address marks are used by the drive to verify that it has positioned correctly before reading and writing, and the data marks have stuff like CRC correction codes, etc. This is not the same as the file tags which MFS (and maybe HFS) puts out there. When the drive says that it cannot find the sector, it probably means that the address marks have been trash. Once that happens, that sector is gone for good. There might be something like an extended write (I have never used fedit, so I don't know) that would let you write the sector over with zeros or something, but short of that, you will have to reformat the disk to get it back. Plan: edit the sector out of the file that references it, by diddling the volume allocation block map. Be very carful. Allocate some other sector, fill it with zeros, and put it in the bad sectors place. Now, copy all the files to another disk, and reformat that one. Voila! Everything is ok, except that you lost a sector. Too bad. scott out.
gus@Shasta.UUCP (05/02/86)
> *** 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.
gijs@ark.UUCP (Gijs Mos) (05/05/86)
In article <545@Navajo.ARPA> wert@Navajo.UUCP (Scott Comer) writes: >Plan: edit the sector out of the file that references it, by >diddling the volume allocation block map. Be very carful. Allocate >some other sector, fill it with zeros, and put it in the bad sectors >place. Now, copy all the files to another disk, and reformat that >one. Voila! Everything is ok, except that you lost a sector. Too bad. Help!!. Just copy the disk with a copy program (like Copy II in sector mode) that ignores the bad sectors. Gijs -- Gijs Mos EUNET: gijs@vu44 ({seismo,philabs,decvax}!mcvax!vu44!gijs) BITNET: u00131@hasara5 FIDO: gijs.mos @ net 500, node 11 MAIL: Gijs Mos Vrije Universiteit Biologisch Lab. De Boelelaan 1087 1081 HV Amsterdam PHONE: +31 20 5485705