[Info-vax] analyze/disk errors

[tadamsmar]

On Friday, November 22, 2013 7:34:07 AM UTC-5, Simon Clubley wrote:
> On 2013-11-22, abrsvc <dansabrservices at yahoo.com> wrote:
> 
> > BITMAP.SYS is always FID 2,2 and contains info to describe the allocation
> 
> > status of the blocks on disk.   A BACKUP/RESTORE operation will re-create the
> 
> > file as the blocks are usually allocated during the restore operation and are
> 
> > not likely to be in the same state as before the backup/restore operation.  See
> 
> > "VMS File System Internals" by Kirby McCoy for more info on this.
> 
> >
> 
> > Dan
> 
> 
> 
> Oh, I know bitmap.sys _should_ always be (2,2) Dan, but it sounds like the
> 
> OP has been copying some files with reserved FIDs in [000000] in order to
> 
> "try" and fix some problems.
> 
> 
> 
> If he actually did that, then bitmap.sys would get a new FID and the question
> 
> then becomes what does the VMS filesystem code do about that ?
> 
> 
> 
> Does it lookup bitmap.sys in [000000] (and then lookup the new mapping in
> 
> indexf.sys) or does it try opening (2,2) directly ? (At which point you
> 
> would now have a massive problem.) If the former, it would presumably only
> 
> do it at volume mount time and hence you would still now have a massive
> 
> problem.
> 
> 
> 
> What happens when bitmap.sys gets purged and the old (2,2) version isn't on
> 
> disk any more ? Does the filesystem code lookup (2,2) in indexf.sys and
> 
> use whatever mapping is assigned for that FID and hence writing over
> 
> whatever might have taken over those blocks ?
> 
> 
> 
> It's unknown questions like that which caused me to recommend, once he
> 
> appeared to be suggesting he had moved files around in [000000], to
> 
> restore the disk set from a backup.
> 
> 
> 
> Simon.
> 
> 
> 
> -- 
> 
> Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
> 
> Microsoft: Bringing you 1980s technology to a 21st century world

Note that I did not copy any [000000].  I tried to copy BADBLK.SYS, but I got an error on the copy command and did not copy it.  Also I tried to copy it to a test directory, not [000000].  So, I did no hack changes to [000000] by copying.  I followed the directions in HELP/MESS for clearing up the errors and it worked on the other files.

To fix BADBCK.SYS I did a image backup and an image restore both with /VERIFY.  Note that this is a shadowed disk system so BADBLK.SYS is not used.

ANAL/DISK runs clean now.  All the files that I fixed by copying were source files or files supporting the code management system (CMS).  The sources compile and the CMS files function with no errors. CMS VERIFY runs clean.

The only odd thing I did that was not exactly what the VMS HELP said was fix BADBLK.SYS without going back to and earlier image backup.  But I really don't care about the contents of the file, since they are ignored as long as I use the disk in a shadow set, if my past testing is correct it gets written over when you add a disk to the shadow set.  If the disk were used non-shadowed, then I could just repopulate BADBLK.SYS anyway.