more on file \"attributes\"

[preece at ccvaxa.UUCP]

> There seems to be no easy answer.  I stand firm with those, however,
> who say don't tamper with the Unix way of storing files.  At least
> 99.99% of all the programs running on Unix machines will be "c"
> programs, which don't need the overhead of having to account for the
> special "fortran" stuff whenever they process files.  (Sorry, pascal
> and lisp programmers, I should lump you in with the "c" people.)
----------
If you really think that 99.99% of all the programs running on Unix
machines will be "c" programs, you haven't dealt with the real world.
There are many, many, MANY sites out there that use almost all their
CPU time running things like SPICE and SPSS and a myriad of other
existing engineering, statistical, and scientific applications written
in (gasp) FORTRAN.

As to where header information should go, I agree that there's no easy
answer.  Putting it outside the file seems preferable to me, because I
think files should be homogeneous and because I hate to think about
random access needing to work around the header and because I like
making it truly invisible to uninformed processes.  This doesn't
violate "the Unix way of storing files" any more than the other
out-of-band information already kept about files.  Certain basic
tools need to know about it (like dump/restore), others simply lose
the data (like sort).  If a vendor chose to add this feature (or
if the standards committee chose to add it), either the existing
commands would grow switches to recognize the header data or new
commands would be added.  No big deal.

I kind of like the idea of a LISP-ish property list (or you could
think of it as a file environment, if you like) in which any arbitrary
(name, value) pairs could be stuck.  Then a getfileproperty call
would get a particular value.

The first rule, of course, has to be to not break existing Unix.

-- 
scott preece
gould/csd - urbana
ihnp4!uiucdcs!ccvaxa!preece