sundar@case.CSNET.UUCP (05/19/86)
I have several problems with the stream interface. Solutions or suggestions to any or all of them would be much appreciated: a) stream_$inquire is not able to inquire files of type dp_dpd (created by dialog) and mbx. For the former, stream_$inquire returns a "not yet implemented" message and the latter, "no active servers" message is returned. It is also not able to inquire about files with UNIX style file names (with special characters and uppercase letters). A temporary fix for the last problem is to quote the name string. b) The insert file "/sys/ins/type_uids.ins.c" declares some uid types, all as external. Looks like they are defined somewhere else. However, nowhere their values are documented (each is a structure with two elements. I found the values using the debugger). The type socket_$uid is not defined anywhere, and the bind complains rightfully so. Also, all the UNIX type files (files with special characters or uppercase letters in their names) do not have seem to have a defined type. c) I need to access the ACLs of some files from within a program. In addition, I need to set them in a special way from within the same program. However, I can't find any system calls to do the job. Hopefully that information is not propreitary. sundar r. iyengar arpa: sundar.case@csnet-relay 531, crawford hall csnet: sundar@case case western reserve university uucp: decvax!cwruecmp!sundar cleveland, oh 44106
mishkin@apollo.UUCP.UUCP (05/22/86)
a) stream_$inquire is not able to inquire files of type dp_dpd
(created by dialog) and mbx. For the former, stream_$inquire returns
a "not yet implemented" message and the latter, "no active servers"
message is returned. It is also not able to inquire about files
with UNIX style file names (with special characters and uppercase
letters). A temporary fix for the last problem is to quote the
name string.
Streams can access a file only if it has Streams type managers for
the file's type. Currently, there is not a type manager for the "dp_dpd"
type.
The problem with "mbx" type files is that you're presumably calling
"stream_$inquire" with "stream_$name_conditional" or
"stream_$name_unconditional" option. (I.e. you're supplying a pathname
as input rather than a stream ID.) The implementation of this style
of "stream_$inquire" implicitly tries to open a stream to the object
with "inquire-only" mode. Unfortunately, the "mbx" Stream manager is
not clever enough to see that it should be in "inquire-only" mode and
instead it tries to actually open an MBX channel. Presumably, there
were no actual MBX servers at the time you made the call and this is
why you got an error. We'll fix the MBX manager to be more clever.
b) The insert file "/sys/ins/type_uids.ins.c" declares some uid
types, all as external. Looks like they are defined somewhere else.
However, nowhere their values are documented (each is a structure
with two elements. I found the values using the debugger). The
type socket_$uid is not defined anywhere, and the bind complains
rightfully so. Also, all the UNIX type files (files with special
characters or uppercase letters in their names) do not have seem
to have a defined type.
The values of these variables are generally not of interest to anyone
-- they're just unique identifiers for types. The exist for two reasons:
(1) so you can write code like:
type := --- get type UID of file ---
if type = uasc_$uid then
--- do something for UASC files ---
and (2) so that with the new Stream interface (released at sr9.2), you
can create files of any type:
ios_$create('foo', ..., records_$uid, id, status);
Note that in neither case do you actually need to know what the value
of those variables are. The "socket_$uid" thing is a bug that was fixed
at sr9.2. The correct name is "tcp_$uid". The variable named in the
old include file was not defined anywhere, hence causing the bind error
you saw.
c) I need to access the ACLs of some files from within a program.
In addition, I need to set them in a special way from within the
same program. However, I can't find any system calls to do the
job. Hopefully that information is not propreitary.
Unfortunately, calls to do what you want are not released. Considering
the fact that many people think that ACLs are too complicated and that
we should simply stick to the Unix user-group-world style of protection,
I don't know whether the ACL calls will ever be released. (The Unix
protection calls -- chmod(2), etc. -- are, of course, usable.)
-- Nat Mishkin
Apollo Computer Inc.
apollo!mishkin
-------