[no subject]

[Ed Barton <EB at MIT-OZ>]

    Date: Thursday, 4 November 1982  14:28-EST
    Sender: DICK at MIT-OZ
    From: Dick@MIT-MC
    To:   bug-maclisp at MIT-OZ
    On the 20 (i.e. OZ) both lisp and the complr open their files in a
    restricted mode that makes it impossible for anything else to touch
    the files.  For example, the exec won't even show that they exist or 
    anything.  
    Most of the time this dosn't matter, but consider the following situation.
    The compiler dies in a strange state, and you are trying to figure out what
    is going on.  Under ITS you could always go into ddt and look at the _unfa_
    file in order to get some idea about what was going on.  On OZ you cannot
    do that becuase though the file is there, it is restricted and you cannot 
    touch it.  In particular, you cannot close it, so when the complr fork
    is killed, the file is automatically deleted.
    It seems to me that things would be a great deal more convenient if
    lisp in general and the complr in particular just opened files normally.
			    Dick Waters

Does nobody fix LISP bugs?  I sent numerous bug reports about this
years ago and the response from JONL was that LISP didn't do what LISP
in fact does, that is, open the JFN in restricted mode.  Then a few
months later someone (on the west coast, I believe) ran into the same
problem and got the same response, but tracked down the place IN THE
CODE where LISP was opening its JFNs in restricted mode.  Now it seems
to me that once the offending piece of code has been identified, that is
sufficient both to prove that LISP is guilty of this paranoid behavior
and to show the implementors how to fix it.  But No.... I just opened
a file with Lisp on OZ and its JFN didn't even show up in the exec's
@i files printout.  SYSDPY told me it was there, though, assigned in
restricted mode just like the old bug.
-------