home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!munnari.oz.au!spool.mu.edu!yale.edu!yale!gumby!destroyer!news.itd.umich.edu!pisa.citi.umich.edu!rees
- From: rees@pisa.citi.umich.edu (Jim Rees)
- Newsgroups: comp.sys.apollo
- Subject: Re: Dealing with a badspot
- Date: 4 Jan 1993 20:53:49 GMT
- Organization: University of Michigan CITI
- Lines: 20
- Distribution: world
- Message-ID: <5d5ed8b8.1bc5b@pisa.citi.umich.edu>
- References: <1993Jan4.100208.10425@infolog.se>
- Reply-To: Jim.Rees@umich.edu
- NNTP-Posting-Host: pisa.citi.umich.edu
-
- In article <1993Jan4.100208.10425@infolog.se>, rabbe@infolog.se (Rabbe Fogelholm) writes:
-
- The UID above refers to the faulty file; I found out by using UCTOB
- and CTOB (surely there should be a more elegant way to find the UID of
- a file).
-
- You can get a program called "luids" from archive.umich.edu that will tell
- you the uids (object, parent, owner, etc) associated with a file.
-
- Does this indicate a so-called badspot? Could I use INVOL option 9 to
- add it to the existing badspot list?
-
- You could, but it would be better to reformat the track with fixvol. See
- the FAQ for a discussion of both methods. You'll also want to run lsyserr,
- and if the disk appears to be deteriorating, you will want to reformat the
- whole thing.
-
- Since you've got a bad vtoc block, there will be a large chunk of the file
- that you can't get at. After repairing the disk you'll have to restore the
- file from backup.
-