Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site eagle.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!lll-crg!dual!qantel!ihnp4!mhuxn!mhuxr!ulysses!eagle!mjs From: mjs@eagle.UUCP (M.J.Shannon) Newsgroups: net.unix-wizards Subject: Re: more on file \"attributes\" Message-ID: <1314@eagle.UUCP> Date: Thu, 8-Aug-85 07:49:36 EDT Article-I.D.: eagle.1314 Posted: Thu Aug 8 07:49:36 1985 Date-Received: Mon, 12-Aug-85 05:24:02 EDT References: <3398@decwrl.UUCP> <2000018@ccvaxa> Organization: AT&T Information Systems, Summit, NJ Lines: 55 > 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.