From: leichter@lrw.com (Jerry Leichter)
Newsgroups: comp.os.vms
Subject: RE: How to get files in SYSLOST back to right place
Date: 15 Nov 92 02:57:17 GMT
Distribution: world
Organization: The Internet


	Please excuse my ignorance.  I'm running VMS 5.3 on a uVAX 3900 and
	did an ANALYZE/DISK/REPAIR and got 435 lost files in
	DUA0:[SYSLOST...].  In looking at these files, I noticed that there
	are duplicate files here.  For example,

	SYSTEM> sh def
	  DUA0:[SYSLOST]
	SYSTEM> dir/file 424.net,[.bp]424.net,dua0:[garn.pdp.bp]424.net

	Directory DUA0:[SYSLOST]

	424.NET;2            (18089,2,0)        

	Total of 1 file.

	Directory DUA0:[SYSLOST.BP]

	424.NET;2            (18089,2,0)        

	Total of 1 file.

	Directory DUA0:[GARN.PDP.BP]

	424.NET;2            (18089,2,0)        

	Total of 1 file.

	Grand total of 3 directories, 3 files.

	By the file id, these are all the same file, so if I delete one, I
	delete them all, right?  

No.  The story is a bit more involved.

A file is defined by its file id - one file id, one file.  A directory is
simply a way of providing meaningful names for file id's; it's a collection
of file name/file id pairs.  The same file id can be listed under multiple
names in the same or multiple directories.  No one of these file entries, in
and of itself, is more properly THE file's name than any other; they are all
equal.  And in VMS prior to V5.0, that's how they were treated:  As equals.
If you deleted any one entry, it and the file itself vanished.  Any additional
entries stayed around, but if you tried to access the file they pointed to,
you got a "no such file" error.

VMS V5.0 changed that.  Each file has in its header a file name and a single
file entry backpointer.  The backpointer is simply the file id of a directory
where the file (probably) has a directory entry under the name retained in
the header.  The directory backpointer was always present, even prior to V5.0,
but it wasn't used for much.  V5.0 gave it a new significance:  IF there is a
backpointer, AND the directory that the backpointer points to actually has an
entry for this file under the file name stored in the header, then that
directory entry is designated a primary entry, and all remaining entries are
designated secondary entries.  When a primary entry is deleted, the file it
points to is deleted as well.  When a secondary entry is deleted, the file
isn't touched - only the entry goes away.  (If a file has no primary entry,
as I recall VMS acts as it did prior to V5.0.  In essense, if there's no
real primary entry, all the entries act as primaries.)

When you create a file and enter it in a directory, that entry becomes the
primary entry.  Additional entries can be created using ACP calls, or more
likely from DCL with the SET FILE/ENTER command.  A file entry, primary or
secondary, can be deleted WITHOUT touching the underlying file with the
SET FILE/REMOVE command.

When you use ANALYZE/DISK, it finds every file id and every file entry in
every directory.  If any file is found not to have a file entry for it
anywhere, it is considered lost.  ANALYZE/DISK/REPAIR places all lost files
in [SYSLOST].  It uses the file name stored in the file's header, but makes
no attempt to use the directory backpointer.

Your three file entries are a bit of a mystery.  Since there are two valid
directory entries for the file, ANALYZE/DISK should not have decided it was
lost, hence should not have put it in [SYSLOST].  Part of the explanation
may be that the file BP.DIR was lost - that's the only way you could have
ended up with a BP subdirectory of [SYSLOST].  But the rest of the dynamics,
I can't explain.

	First question.  How do I get these 3 files back to one?

There really only is one file; you just have two extra entries for it.  You
can remove them safely with SET FILE/REMOVE.  After you do that, do another
ANALYZE/DISK/REPAIR.  It should fix up the backpointer for the file to
point to the one remaining entry.

	Second question. Is there a way to find out where a lost file came
	from so I can put it back, or do I tell the owner of these files to
	figure it out for themself?

It depends.  If we consider files that don't have multiple entries, you have
the file name and can determine the directory from the header backpointer.
This is a tedious task to do by hand - you have the file id for what should
be a directory file.  You have to find the corresponding file header (this
can be done by dumping the right portion of the index file), then look at it
to determine its name and (most likely) the file id for the entry IT can be
found in.  Repeat until you've gotten to the MFD.  Anyone have a little
program to automate this?  It's a major pain in the rear to do by hand.

Of course, this assumes that the backlinks are valid.  They may not be, in
which case it's impossible, in general, to determine where the file came
from.

It's always impossible to determine what secondary entries may have existed
for the file; that information is simply not in the file itself.

Finally, it sounds to me as if your disk has had a hard time of it.  If I
were you, I'd watch it VERY carefully for signs of a hardware problem.

							-- Jerry