more on file \"attributes\"

[preece at ccvaxa.UUCP]

> 1) There is no such "file information block", strictly speaking, on
> UNIX.
----------
There's a lot of stuff in the inode that looks an awful lot like a file
information block. [It would be cute if there were more room in the
directory entry -- then we could have separate attribute lists for
each link to a file...]
----------
> 2) How does putting it in the "file information block" (whatever that
> may be in UNIX - the inode, I presume) make it "copied transparently
> when you make a copy of the file"?
----------
Obviously, it doesn't.  On the other hand, except for dump/restore, it
would be sufficient to have open(2) create an empty one.  Tools to
manipulate it could be handled separately (after you cp the file
you cp_file_properties to get the attribute list), though it
wouldn't be a big deal to make cp and mv handle them, too, and that
is what a vendor who was going to do this would do.
----------
> If, for example, you write files with "FORTRAN carriage control"
> differenly from UNIX text files (with embedded ASCII control characters
> for carriage control), current UNIX utilities will not be able to read
> those files, *unless you change them* - which you say you are not
> suggesting.
----------
Why not?  The utilities may not deal with them intelligently or in the
way intended, but the files themselves would still be just streams of
data bytes, which they would NOT be if you put the header in the file.
Grep, for instance, would find nothing confusing in a file with a
hidden property list, but would find a confusing header if the header
were embedded in the file (confusing in the sense of "containing
stuff other than data" -- it would still be able to process either
kind of file).
----------
> > or write utilities which can look at different files without knowing a
> > priori the file format,

> Why would you want a utility that could work on text files and FORTRAN
> binary files?
----------
You're mis-interpreting "format."  A utility might need to deal with
132 byte records and 80 byte records or with files having carriage
control and files not having carriage control.  There are also, of
course, a lot of useful things you could put in a property list for
use by maintenance programs (such as, perhaps, a more neatly
integrated version control system).
----------
> No program which expects to read text files would be likely to want to
> read a structured file like that.
----------
There are structured files which still have perfectly normal
Unix text file characteristics (a file, for instance, of 81-byte
records containing a newline in byte 80 of each record).

The embedded header approach makes a number of things more difficult,
including random access (offsets have to account for the header) and
use with normal Unix utilities (a filter would be needed before using
, for instance, grep; multi-file commands (such as merge) would need
to have temporaries prepared, since you couldn't provide filtering
on more than one file through a pipe).
----------
> but all this has been said before; you've provided no new arguments in
> favor of adding attributes like that to UNIX files.
----------
I'm not holding my breath.  I think they would be useful and would help
sell into a few new markets, but I don't think we can't live without
them.

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