more on file \"attributes\"

M.J.Shannon mjs at eagle.UUCP
Thu Aug 8 21:49:36 AEST 1985


> 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.

By and large, the only files in a UNIX system that are homogeneous are text
files.  Granted, these files probably account for the vast majority of files,
but what about object modules, libraries of same, and executables?  None of
these are homogeneous, but no utilities (like cat, cp, wc, ls, etc.) have any
trouble with them simply because they're not.

> 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).

Lose the data?  You mean you'd prefer a copy of a file not to have any of the
attributes of the original?  That seems to me to forbid copying of executables
(the non-homogeneous header gets lost in the shuffle, preventing execution of
the copy).  Sorry, this *DOES* violate "the UNIX way of storing files".

> 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.

No big deal?  Would you like to add major sections to *every* command that
manipulates files to figure out its attributes?  Or would you prefer to write N
versions of each of those commands?

> 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.

This sounds reasonable, but why specify that it isn't part of the file data
itself?  Most files that have headers on them have a fixed property list, with
the names (and types) defined in structures in /usr/include.  Before you
propose a new mechanism, you'll have to convince a whole host of people that
their software is broken.  Good luck.

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

But that seems to be the first rule broken when you propose that these
attributes be stored anywhere but in the data of the file.

> scott preece
-- 
	Marty Shannon
UUCP:	ihnp4!eagle!mjs
Phone:	+1 201 522 6063

Warped people are throwbacks from the days of the United Federation of Planets.



More information about the Comp.unix.wizards mailing list