Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!att!dptg!ulysses!andante!alice!andrew From: andrew@alice.att.com (Andrew Hume) Newsgroups: comp.unix.wizards Subject: Re: file attributes Summary: a clarification of the issues Message-ID: <20439@alice.att.com> Date: 22 Jun 91 08:31:56 GMT References: <1743@sranha.sra.co.jp> Organization: AT&T Bell Laboratories, Murray Hill NJ Lines: 56 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.