Although I agree that data announcement is becoming necessary, putting
it in the file is the wrong answer, because that requires that all programs
be modified* to reflect that, and that some programs dealing with binary
data as "images" will have a fair amount of extra trouble dealing with it.
(It's very nice to have data aligned at zero in a file.)
(* Yes, I realize that open could do an lseek, but that's pretty ugly,
and likely to end up with some real disasters in some programs: is
rewind() still equal to lseek(0,0)?)
Additionally, simply extending the inode implies something approaching
omniscience on the part of the standardizers; what attributes are needed
and what are "temporary" needs, what are the future needs, and how much
room is "right" for expansion are all rather nasty problems to solve.
One also needs to look at UNIX historically: it is antedated by many, many
filesystems that have file attributes, and one of R&T's goals was to get
away from that, as it got very much in the way of the use of the system.
(Every file had a "type", and operations on one "type" could not be applied
to another, even when it really did make sense.) (See: OS/360 (etc.), GECOS,
MPE, EXEC 8, MCP (Burroughs), etc.) (It was put another way: UNIX only
has files, not "types of files".)
The fact that UNIX doesn't have typed files in the sense of this discussion
is NOT an accident, and is NOT the consequence of "sloppy design", but rather
quite intentional and thought out. (Too strongly) typed files are more
trouble than they're worth!
To me, what makes sense is to develop a convention where if there is typing
information on a file, it is somehow associated with the file by name
and location, in another ordinary file. Yes, I realize that this creates
a bookkeeping mess (and thus is a "research problem") but it doesn't
violate the design of UNIX (which is "kiss") and it doesn't change the
interfaces. (Example: for each file <foo.bar> if there exists a
file .,<foo.bar> (leading . to make it invisible, "," to keep it pretty
unique) then that file contains typing information. By using a text file
with "field name: value" type of format, it's infinitely extendable without
ever breaking existing programs (if they're written from the beginning to
ignore fields they don't understand). Remember, this is an example of
my thinking, not a proposal; criticizm of the choice of characters and the
like should be met with derision. (There; that should make everyone read
what I said, not what they thought I said.))
Donn