[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Terminology and resolution of "restricted JFN" problem; and functions OPENF and TNX-GTJFN
- To: Feinberg at CMU-20C
- Subject: Terminology and resolution of "restricted JFN" problem; and functions OPENF and TNX-GTJFN
- From: Jon L White <JONL at MIT-MC>
- Date: Fri, 5 Mar 82 16:20:00 GMT
- Cc: BUG-MACLISP at MIT-MC, BUG-TWENEX at MIT-MC
- Original-date: 5 March 1982 11:20-EST
Date: 2 March 1982 21:59-EST (Tuesday)
From: FEINBERG at CMU-20C
Subject: Why does @INFORMATION (ABOUT) FILES ... say "restricted JFN"?
I beg to differ with you, JONL. Here is a excerpt from
. . .
The line MOVSI 1,(GJ%ACC+GJ%SHT) sets the Restricted Access bit.
. . .
Since I offered the ARYFIL package as a way to get a "handle" on any
JFN created by LISP, I assumed the complaint from EB was related to
"restricted" access of files. My "denial" only applies to the file
access, which @INFORMATION (ABOUT) FILE... doesn't pertain; in fact
I am the one who was confused for thinking that the @INFORMATION
command tells you anything at all about the file access mode, as
opposed to the JFN access.
But back to the point which raised this issue -- I'd be reluctant to make
such a sweeping change (removing all the GJ%ACC bits) from LISP system
code since it was put there in the first place to protect LISP from
randomness. If an application intends to hack multiple forking (such as
LEDIT does) then it will likely have the SUBFORK package loaded. SUBFORK
has the function OPENF which allows you to specify both the JFN mode and
file-access mode for opening files, and the function TNX-GTJFN which
allows you to specify the JFN mode for random GTJFN's.