NetNews Usenet Archive 1992 #27/NN_1992_27.iso/spool/comp/os/vms/18129

Internet Message Format | 1992-11-17 | 3.9 KB

Path: sparky!uunet!charon.amdahl.com!pacbell.com!sgiblab!sdd.hp.com!elroy.jpl.nasa.gov!nntp-server.caltech.edu!SOL1.GPS.CALTECH.EDU!CARL
From: [e-mail] (Carl J Lydick)
Newsgroups: comp.os.vms
Subject: RE: How to get files in SYSLOST back to right place
Date: 18 Nov 1992 01:32:02 GMT
Organization: HST Wide Field/Planetary Camera
Lines: 67
Distribution: world
Message-ID: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
NNTP-Posting-Host: sol1.gps.caltech.edu

In article <[e-mail]>, [e-mail] (Jerry Leichter) writes:
=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.

It's easy.  First, note that it wasn't really BP.DIR that was lost, it was
GARN.DIR.  VERIFY discovered the files in the lost directories didn't have
directory entries that could be found by traversing the directory tree starting
with [000000]000000.DIR;1.  Hence it placed them in SYSLOST.  Then it found
BP.DIR and put it in SYSLOST.  Finally, it ran across GARN.DIR and put it in
SYSLOST.  We end up with:

                 [SYSLOST]
                                  |    | |
                                [GARN] | |
                                    |  | |
                                    [BP] |
                      |  |
                                    (files)

=    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.

Actually, he wants to:
    $ SET FILE/NODIR [SYSLOST]BP.DIR;1
    $ SET FILE/REMOVE [SYSLOST]BP.DIR;1
then for each file that occurs in both [SYSLOST] and [SYSLOST.GARN.BP]
    $ SET FILE/REMOVE [SYSLOST]file_name

=    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.

'Fraid not.  Once the file's been put in SYSLOST, its backpointer is set to the
FID of [000000]SYSLOST.DIR;1.  You COULD, of course,
    $ DEFINE SYS$OUTPUT some.file
    $ ANALYZE/DISK/NOREPAIR your_disk:
then go wading through some.file and find the FIDs of all the files that
weren't found in directories.  But you have to do this BEFORE the files show up
in [SYSLOST].
=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.

I used to have one written in DCL.  If there's much interest, I could try to
figure out where I put it.
--------------------------------------------------------------------------------
Carl J Lydick | INTERnet: [e-mail] | NSI/HEPnet: SOL1::CARL

Disclaimer:  Hey, I understand VAXen and VMS.  That's what I get paid for.  My
understanding of astronomy is purely at the amateur level (or below).  So
unless what I'm saying is directly related to VAX/VMS, don't hold me or my
organization responsible for it.  If it IS related to VAX/VMS, you can try to
hold me responsible for it, but my organization had nothing to do with it.