home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #31 / NN_1992_31.iso / spool / comp / os / vms / 20242 < prev    next >
Encoding:
Internet Message Format  |  1993-01-03  |  2.3 KB
  1. Path: sparky!uunet!zaphod.mps.ohio-state.edu!wupost!waikato.ac.nz!comp.vuw.ac.nz!zl2tnm!toyunix!don
  2. Newsgroups: comp.os.vms
  3. Subject: Re: HELP!!! Security problem for gurus. [Directories]
  4. Message-ID: <14628002@zl2tnm.gen.nz>
  5. From: don@zl2tnm.gen.nz (Don Stokes)
  6. Date: 3 Jan 93 12:00:19 GMT
  7. Sender: news@zl2tnm.gen.nz (GNEWS Version 2.0 news poster.)
  8. References: <1i6dd2INNrct@gap.caltech.edu>
  9. Distribution: world
  10. Organization: The Wolery
  11. Lines: 35
  12.  
  13. carl@SOL1.GPS.CALTECH.EDU (Carl J Lydick) writes:
  14. > You shouldn't be surprised.  You see, RMS is also a *CRITICAL* entity.  If it
  15. > runs across something that it doesn't understand, there are a few
  16. > possibilities:
  17. >     1)  The disk is corrupted;
  18. >     2)  The user's address space is corrupted;
  19. >     3)  The system address space  is corrupted;
  20. >     4)  The system disk is corrupted.
  21. > 
  22. > Now, case 1 might not warrant a bugcheck.  Case 2 should, at the very least,
  23. > result in process deletion;  Cases 3 and 4 both warrant a system crash before
  24. > corrupted memory/system disk can do any more damage.  The idea is to have the
  25. > system fail safe:  When in doubt, do whatever's most likely to insure the
  26. > integrity of the system;  if that means getting the system manager's attention
  27. > with a >>> prompt on the console, so be it.
  28.  
  29. RMS won't crash a system at all (unless BUGCHECKFATAL is set).  The XQP might.
  30. RMS lives in exec mode; an unhandled condition will at worst take out the 
  31. process.  
  32.  
  33. As for case (4), a corrupt system disk is _not_ a good reason to crash
  34. the system.  In many cases keeping the thing up could be the difference
  35. between a clean recovery and having to restore from backup (possibly
  36. causing loss of data from between the last backup and the crash, at
  37. best losing valuable production time); ANALYZE/DISK/REPAIR _does_ work
  38. on a system disk.  Of course if it's really scrozzled you might need to
  39. crash it and restore anyway.  I can't think of any reason for the system
  40. to crash because it discovers a damaged file structure (as opposed to
  41. crashing because it ate something poisonous as a result), nor can I recall
  42. anyone losing a system because of file structure damage.
  43.  
  44. --
  45. Don Stokes, ZL2TNM (DS555)                        don@zl2tnm.gen.nz (home)
  46. Network Manager, Computing Services Centre            don@vuw.ac.nz (work)
  47. Victoria University of Wellington, New Zealand              +64-4-495-5052
  48.