Article 172360 of comp.os.vms:
Tim Llewellyn wrote:
> 
> This is the output of disk analysis on that system (I don't want to
> repair now).
> 
> $ anal/disk/norepair sys$sysdevice:
> Analyze/Disk_Structure for _DISK3$DIA3: started on 18-JUN-1997
> 17:27:24.89
> 
> %ANALDISK-I-OPENQUOTA, error opening QUOTA.SYS
> -SYSTEM-W-NOSUCHFILE, no such file
> %ANALDISK-W-DELHEADER, file (1222,2,1) SYS.EXE;2
>         marked for delete
> 
> So, it appears to me that there are no lost files. Sorry, I forgot to
> post this info yesterday.

I'll bet you have a problem with back links. Every file has a link that
points back to its primary directory entry. This allows the file system
and utilities to distinguish between a file's primary name and aliases.

For a long time people have complained that image BACKUP found files
under whatever directory entry it encountered first, and a non-image
backup would save a file with aliases multiple times. Round about V6.1
BACKUP started to special-case aliases to solve these problems.
Basically, this means that BACKUP waits to save a file until it
encounters its primary name. However, if the file's backlink is screwed
up, this may mean that BACKUP will never find a valid primary name and
so the file shows up as lost.

You can inspect a file's backlink by doing a DUMP/HEADER/BLOCKS=END=0.
The backlink logically consists of a parent directory FID and the file
name string in the header. Have a look in particular at your top level
system directories. The sum total of the files that are coming up lost
should have a small set of common parent directories. These are the most
likely culprits.

Fixing a broken backlink is a tricky business and depends on what it
looks like. Basically, what you have to accomplish is to create a
directory entry for the file that matches its current backlink, both in
parent directory FID and name. That name becomes the primary name. Now
if you do a SET FILE /REMOVE on that name, the file's backlink will be
erased, so that the file is marked as having no primary directory entry.
Now take the directory entry that you want to be the primary name and
rename it to itself. The act of re-entering the name in the presence of
no backlink in the file establishes a new backlink pointing to the newly
entered name.

The VMS$COMMON directory is a likely candidate for backlink screwups
because it appears in different directories under different names. Its
primary name is supposed to be [000000]VMS$COMMON.DIR. However, in the
[SYSn] directories it appears as SYSCOMMON.DIR. In past versions of VMS,
an image save and restore of the system disk could end up with
VMS$COMMON.DIR having a backlink FID that pointed back to the MFD, but
with a name of SYSCOMMON.DIR recorded in the header. (Or maybe the other
way round; point is either way is an invalid backlink.) So as an
example, you would apply the above procedure to this case by renaming
[000000]VMS$COMMON.DIR to [00000]SYSCOMMON.DIR and back.