file attributes

[Andrew Hume]

	I would be the last person to kill a heated discussion by
trying to clarify what is being said but i feel strongly enough
about file attributes that i want people to understand what is going on.
(at least, as far as i am concerned.)

	In Unix, files are a byte stream plus a small number of attributes.
These latter are stored in the inode and made available to the user by
a small number of system calls (stat, fstat). Erik raised the issue of
attributes and mentioned an example, the application identifier used
by the Macintosh Finder to execute a file.

	As has been pointed out, most strongly by Doug Gwyn, it is
simply not Unix to mandate processing of a file by a particular
application. But if we change this to being the preferred application,
instead of the mandatory application, then it is much more reasonable idea.
And this is a much better solution than the Unix hack of the first line being
#application-binary args
(what if the application doesn't use # as a comment?). In this way, you
can still od or whatever the file, but if the shell (or whatever) wants to
launch it, it can ask the best choice of program to run.

	If this were the only attribute, then the pitiful solutions of
.desktop etc would be tolerable; after all, they only need everyone to
follow a convention and need no new system calls. But the simple fact is,
it isn't the only attribute. What about ACLs for a file? What about
storing author and processing information? Sure enough, if you whine
enough about new system calls, you will develop systems involving
either multiple files or ascii/binary headers. Both of these are
problematic. Why can't I rename a dbm database by saying
	mv old new
?? Why do i have to say
	mv old.T new.T && mv old.F new.F
(or similar). And who polices, documents and maintains the arbitrary
system of mapping filename suffixes to properties? As for headers,
sure, file can recognise a whole bunch. And it gets it wrong, too,
a fair bit of the time. ascii headers have some nice properties;
tom duff's graphics code has ascii headers in front of all his
pictures (terminated by \n\n). They record a bunch of stuff about the
picture and even how it was made (what programs were run to generate it).
BUT, every program that looks at these files, has to know how to skip a
variable sized amount of goo before starting. what should wc do?
what should sort do?

	Unix has always tried to be more honest than most OSs about this
sort of thing. Why not add one more system call (if you really hate this,
then standardise a way in via fcntl), say getattr, that is analogous to
stat and returns the value of an ascii attribute name? Then the files
can go back to being byte streams and for the people who need them,
attributes are available with no impact to people who don't use them.
Of course, some programs, such as mv, cp, tar etc, will need training
to cope with this, but it seems manageable. At least, the user is relatively
unimpacted. Of course, as peaple have been discussing for years now,
supporting typed data with general Unix tools has many problems, but they
seem cleaner and more manageable than the hacky solutions mentioned above.