Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!samsung!sdd.hp.com!wuarchive!udel!ee.udel.edu
From: new@ee.udel.edu (Darren New)
Newsgroups: comp.os.misc
Subject: Re: What constitutes a good OS?
Message-ID: <42346@nigel.ee.udel.edu>
Date: 21 Jan 91 21:12:38 GMT
References: <5362@auspex.auspex.com> <42128@nigel.ee.udel.edu> <5392@auspex.auspex.com>
Sender: usenet@ee.udel.edu
Organization: University of Delaware
Lines: 213
Nntp-Posting-Host: estelle.ee.udel.edu

In article <5392@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes:
>They may change, or they may not.  According to an EDT manual lying
>around here, EDT will try to use decimal fractions for line numbers in
>order to avoid renumbering lines, but "in extreme cases EDT may be
>forced to renumber lines after the last line you insert".  

Edit (under CP-V) would simply bop you out of insert mode if you
tried to insert something between 1736.165 and 1736.166.

>In that case, as far as I know, in RSX and VMS, text files consist of
>lines, not records, and files don't have line numbers as keys, by those
>definitions.  (Text files aren't random-access files.  You *might* be
>able to replace a line with a shorter line, but not with a longer line,
>and probably not even with a shorter line.  Line numbers are attributes
>hung off lines, but aren't keys for random access.)

What a shame. Then editors have to read an entire file and then write it
back out again to make one change in the middle. The line numbers become
the equivalent of card sequence numbers. Yuk.

>I've never seen a system that uses records, by that definition, as
>lines, nor any that use line numbers as keys.  I presume you have.

Yes, CP-V and CP6 both have such file types.  Makes life much easier,
believe me.

>(This
>is another case, like the case of keyed files, where having an abstract
>"stream read" operation works a bit better than an abstract "stream write"
>operation; the "stream read" operation generally only has to *discard*
>data to make a more complexly-structured file look like a stream of
>lines or whatever, while a "stream write" operation would have to *add*
>data, and few systems implement the Read User's Mind operation.)

Agreed.  I don't see any problem with making a poor guess or allowing
a simple file type (stream or non-keyed records) to coexist with
keyed files.

>It wasn't a problem because text files weren't keyed files, or it wasn't
>a problem because all the editors knew about keys?

It wasn't a problem because the editor could read unkeyed files and put
keys on if you wanted. More important, you rarely actually edited files
that were generated in such a way as to require keys; that is, the files
that were generated consecutively were not often modified randomly, and
when they were you just had to put on the keys.  Since the keys had no
significance to the contents, the lack of good initial keys was not a
problem in practice.

I can see where putting the "correct" keys on might be useful. For example,
the Pascal compiler could put error messages in a specially-flagged comment:
    {%%% Error 104: Undefined variable}
and key it in such a way that the error message could be merged into
the source at the correct place. The special tag could make the errors
easy to delete. The compiler could check to see if the error message is
already there in the source and not generate it again if it is.

>Well, maybe.  What happens if - let's use the example you chose of "the
>tools that make UNIX useful", under the assumption that many of them are
>programs whose output is a character-stream or byte-stream file - you
>need to have one of those programs generate a file with stuff in the
>resource fork?  

This is unfair, but let me answer first before I explain.
Take, for example, kermit on the Mac. That implementation has been
changed to recognise an initial tag during the download of the
resource fork of a file. That is, if the initial N bytes of a
binary transfer are 0x????????, then that download is read into
the resource fork. Upon upload, the user is prompted on whether
to read or write the resource fork.

On the Mac, there are both a character-byte-stream oriented portion,
and a "resource" object-oriented portion (kind of). When you create
a file, you must tell the OS the type of the file and who is creating
it. The type is used to allow programs to recognise compatible
files and to get the right icon for the file when the program
writes several kinds of files (e.g., tables, reports, views, ...).
The creator is used when the file is openned to determine which
application should be started. Every open call must specify these
two parameters. I would imagine that an fopen() implementation
would have values hardcoded in or fetched from the environment in
some way.  However, this info must be specified somewhere.

The resource-oriented files are accessed in a different way, closer
to mmap() than anything else. You ask for a particular resource, and
you get a pointer to it. You can change it and write it back, or
create new empty resources. 

The reason I claim that the question is unfair is that there is no need
for the UNIX-like programs to put stuff in the resource fork. What goes
in the resource fork is Mac-specific, and UNIX ports don't use
Mac-specific stuff.  The tools that make the Mac useful either put the
correct stuff into the resource fork because that is their job (like a
font installer) or they don't need to change the resource fork at all
(like a text editor).  What makes the resource fork useful is that
things there can be changed after the application is compiled, new
items can be added that are never looked at by the originating
application, and so on.

>Again, this sounds like a case where providing a "stream of lines"
>read interface to a structured file is easy, but providing a "stream of
>lines" write interface to a structured file isn't so easy.

Correct. Specifically, the Mac stores text like UNIX does, so the
"stream of lines" is the same on both. However, if I'm not speaking
English, I can modify all the Mac menus to be written in (say) German.
This is because I can change the menus in the resource fork, making
them different sizes and in different places, and not screw up anything
else.

>>>(In other words, can you use PIP to copy an ISAM file, and have the
>>>copied file usable as an ISAM file?)
>>I would hope so.  Maybe I have not used any *really bad* implementations
>>of a complex file system.
>I don't know which systems let you do that 

Again, CP-V and (I understand) CP6 would allow you to even write
keyed files to a tape, allowing you to access them exactly as if
they were on a disk, random access and all, except that you
could not write them.

> - or how many of them
>accomplish that by not letting you add your own *new* structured file
>types to the system.  

Yes, CP-V was lmited in this way.  I think an extensible file system
would be best, but just a slightly more complex file system would make
much things easier.

>Yup, but now we're back to "tar" managing "tar" files, and SCCS having
>special utilities to manage SCCS files, and....

You are always going to need some lowest-level structure. If all you have
is keyed files, then there won't be any programs that don't write them.
If you have multiple types of files, you need programs to translate
back and forth. The advantage in the latter case is that you dont
have to write those programs yourself!

>I wouldn't necessarily presume that; in some systems, the "abstract"
>file access routines (the ones providing the interface that most
>programs see) are completely unprivileged; 

Actually, I was thinking of the following method to go with my OO
filesystem:  Each file has the "stack" of access mechanisms. The user
may, at open time, ask for new access modes to be added on top (say,
adding stream access on top of keyed files). The access control would
say which modules and which users could send which messages to the
file. So therefore, if you had

access accesscontrol
  handles any
  sends any read-user-account-name
  extra-info
    open(john,bill) read-by-key(bill) read-next(john)
access consec-over-keys
  handles read-next open close
  sends   read-by-key open close
access keys-over-diskblocks
  handles read-by-key open close write-by-key
  sends read-block write-block alloc-block
 
In this case, john and bill can both open the file, bill can read
it randomly and john can read it consecutively. Had the access-control
been put below the consec-over-keys, then all consecutive calls would
have been translated to keyed calls before getting to the access-control
mechanism and the access-control mechanism would not have prevented
bill from reading consecutively.  Of course, some other access control
would be imposed upon creation of the file to prevent read-block and
write-block from being invoked with block numbers not belonging to
that file.

>If you want to have that level of security, I might prefer to have a
>fairly general mechanism to provide it.  

Done. Although under CP-V, I think the answer was that you could
not write unkeyed records to a keyed file and vica versa. On the
other hand, I can imagine a file type where each key consists
of "key+lines" (where there are unkeyed lines after this key
which cannot be accessed except consecutively).

>How much protection do you want to enforce with that level of security?

With an active file system, that level of security is not a problem.

>Do you "draw the line" somewhere and say "stuff below the line is
>protected, stuff above the line isn't"?  (I'm not advocating or
>attacking either technique - there are costs and benefits to both - I'm
>just asking.)

I would let the user draw the line. There is no reason why you could
not allow some users to access stuff based on "key" and others to
access it based on "higher-level-data-type". Right now, UNIX does not
give you that choice either except in the most cumbersum way. There is
nothing that prevents you from corrupting the structure of SCCS files
unless you make a user that owns all the SCCS files on the system and
you only access them through SCCS, in which case you have created an
active file system, and one which does not work well with the rest of
the UNIX tools.

Actually, adding keyed records to UNIX would not be too bad if it could
be done by rewriting fopen, fgets, ....  The only problem would be
with programs that ftell and expect it to be a byte offset into the
file. Then all that would be needed would be recompiling everything.
Extra calls could be used to indicate that a program recognises 
the keyed file and that keyed I/O is requested. Putting keyed files
on top of stream files is not difficult; maintaining the consistancy
is difficult.          -- Darren

-- 
--- Darren New --- Grad Student --- CIS --- Univ. of Delaware ---
----- Network Protocols, Graphics, Programming Languages, 
      Formal Description Techniques (esp. Estelle), Coffee, Amigas -----
              =+=+=+ Let GROPE be an N-tuple where ... +=+=+=