home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / os / vms / 18130 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  5.3 KB
  1. Path: sparky!uunet!charon.amdahl.com!pacbell.com!ames!saimiri.primate.wisc.edu!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!lrw.com!leichter
  2. From: leichter@lrw.com (Jerry Leichter)
  3. Newsgroups: comp.os.vms
  4. Subject: RE: How to get files in SYSLOST back to right place
  5. Message-ID: <9211150358.AA13495@uu3.psi.com>
  6. Date: 15 Nov 92 02:57:17 GMT
  7. Sender: daemon@ucbvax.BERKELEY.EDU
  8. Distribution: world
  9. Organization: The Internet
  10. Lines: 110
  11.  
  12.  
  13.     Please excuse my ignorance.  I'm running VMS 5.3 on a uVAX 3900 and
  14.     did an ANALYZE/DISK/REPAIR and got 435 lost files in
  15.     DUA0:[SYSLOST...].  In looking at these files, I noticed that there
  16.     are duplicate files here.  For example,
  17.  
  18.     SYSTEM> sh def
  19.       DUA0:[SYSLOST]
  20.     SYSTEM> dir/file 424.net,[.bp]424.net,dua0:[garn.pdp.bp]424.net
  21.  
  22.     Directory DUA0:[SYSLOST]
  23.  
  24.     424.NET;2            (18089,2,0)        
  25.  
  26.     Total of 1 file.
  27.  
  28.     Directory DUA0:[SYSLOST.BP]
  29.  
  30.     424.NET;2            (18089,2,0)        
  31.  
  32.     Total of 1 file.
  33.  
  34.     Directory DUA0:[GARN.PDP.BP]
  35.  
  36.     424.NET;2            (18089,2,0)        
  37.  
  38.     Total of 1 file.
  39.  
  40.     Grand total of 3 directories, 3 files.
  41.  
  42.     By the file id, these are all the same file, so if I delete one, I
  43.     delete them all, right?  
  44.  
  45. No.  The story is a bit more involved.
  46.  
  47. A file is defined by its file id - one file id, one file.  A directory is
  48. simply a way of providing meaningful names for file id's; it's a collection
  49. of file name/file id pairs.  The same file id can be listed under multiple
  50. names in the same or multiple directories.  No one of these file entries, in
  51. and of itself, is more properly THE file's name than any other; they are all
  52. equal.  And in VMS prior to V5.0, that's how they were treated:  As equals.
  53. If you deleted any one entry, it and the file itself vanished.  Any additional
  54. entries stayed around, but if you tried to access the file they pointed to,
  55. you got a "no such file" error.
  56.  
  57. VMS V5.0 changed that.  Each file has in its header a file name and a single
  58. file entry backpointer.  The backpointer is simply the file id of a directory
  59. where the file (probably) has a directory entry under the name retained in
  60. the header.  The directory backpointer was always present, even prior to V5.0,
  61. but it wasn't used for much.  V5.0 gave it a new significance:  IF there is a
  62. backpointer, AND the directory that the backpointer points to actually has an
  63. entry for this file under the file name stored in the header, then that
  64. directory entry is designated a primary entry, and all remaining entries are
  65. designated secondary entries.  When a primary entry is deleted, the file it
  66. points to is deleted as well.  When a secondary entry is deleted, the file
  67. isn't touched - only the entry goes away.  (If a file has no primary entry,
  68. as I recall VMS acts as it did prior to V5.0.  In essense, if there's no
  69. real primary entry, all the entries act as primaries.)
  70.  
  71. When you create a file and enter it in a directory, that entry becomes the
  72. primary entry.  Additional entries can be created using ACP calls, or more
  73. likely from DCL with the SET FILE/ENTER command.  A file entry, primary or
  74. secondary, can be deleted WITHOUT touching the underlying file with the
  75. SET FILE/REMOVE command.
  76.  
  77. When you use ANALYZE/DISK, it finds every file id and every file entry in
  78. every directory.  If any file is found not to have a file entry for it
  79. anywhere, it is considered lost.  ANALYZE/DISK/REPAIR places all lost files
  80. in [SYSLOST].  It uses the file name stored in the file's header, but makes
  81. no attempt to use the directory backpointer.
  82.  
  83. Your three file entries are a bit of a mystery.  Since there are two valid
  84. directory entries for the file, ANALYZE/DISK should not have decided it was
  85. lost, hence should not have put it in [SYSLOST].  Part of the explanation
  86. may be that the file BP.DIR was lost - that's the only way you could have
  87. ended up with a BP subdirectory of [SYSLOST].  But the rest of the dynamics,
  88. I can't explain.
  89.  
  90.     First question.  How do I get these 3 files back to one?
  91.  
  92. There really only is one file; you just have two extra entries for it.  You
  93. can remove them safely with SET FILE/REMOVE.  After you do that, do another
  94. ANALYZE/DISK/REPAIR.  It should fix up the backpointer for the file to
  95. point to the one remaining entry.
  96.  
  97.     Second question. Is there a way to find out where a lost file came
  98.     from so I can put it back, or do I tell the owner of these files to
  99.     figure it out for themself?
  100.  
  101. It depends.  If we consider files that don't have multiple entries, you have
  102. the file name and can determine the directory from the header backpointer.
  103. This is a tedious task to do by hand - you have the file id for what should
  104. be a directory file.  You have to find the corresponding file header (this
  105. can be done by dumping the right portion of the index file), then look at it
  106. to determine its name and (most likely) the file id for the entry IT can be
  107. found in.  Repeat until you've gotten to the MFD.  Anyone have a little
  108. program to automate this?  It's a major pain in the rear to do by hand.
  109.  
  110. Of course, this assumes that the backlinks are valid.  They may not be, in
  111. which case it's impossible, in general, to determine where the file came
  112. from.
  113.  
  114. It's always impossible to determine what secondary entries may have existed
  115. for the file; that information is simply not in the file itself.
  116.  
  117. Finally, it sounds to me as if your disk has had a hard time of it.  If I
  118. were you, I'd watch it VERY carefully for signs of a hardware problem.
  119.  
  120.                             -- Jerry
  121.  
  122.