Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!linus!philabs!cmcl2!seismo!harvard!talcott!panda!genrad!decvax!decwrl!sun!guy
From: guy@sun.uucp (Guy Harris)
Newsgroups: net.unix
Subject: Re: more on file \"attributes\"
Message-ID: <2548@sun.uucp>
Date: Fri, 2-Aug-85 04:07:16 EDT
Article-I.D.: sun.2548
Posted: Fri Aug  2 04:07:16 1985
Date-Received: Sun, 4-Aug-85 06:13:14 EDT
References: <3403@decwrl.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 103

> There are many such operating systems (which have file information in
> invisible or hidden headers) around, such as the ATEX text-processing
> system used in many newspapers. Ordinary programs and utilities need
> not ever look at the invisible header if they are interested in the
> data only.
>  
> I suggested that it be part of the "file information block" (i.e.,
> the filename, creation date, and size) because that is a convenient
> way to have it copied transparently when you make a copy of the file
> or rename the file.

1) There is no such "file information block", strictly speaking, on UNIX.
The file name is not stored anywhere with the file (the only place the name
resides is in a directory, unlike in Files-11, where one copy resides in the
"file header" and other copies in the directories that reference the file)
and the creation date/time isn't stored anywhere.

2) How does putting it in the "file information block" (whatever that may be
in UNIX - the inode, I presume) make it "copied transparently when you make
a copy of the file"?  The only way I can interpret "transparently" is that
any software that now copies files will automagically copy the header
information without any change to that software.  This is not the case.  If
the header isn't in the data of the file, it can't be set by doing a "write"
to the file; all the UNIX copy command ("cp") does is:

	open the "from" file for reading
	open the "to" file for writing, truncating it if it
		exists and creating it if it doesn't
	while (data remains to be read from the "from" file) {
		read data from the "from" file
		write it to the "to" file
	}

Nowhere in here is there anything which could set the file type, record
length, etc., etc., etc..  You'd have to hang it off the "open for writing"
operation (that's where the file permission modes are set now).  That would
require "cp" to change, and would require lots of other programs to change
as well.  Hardly transparent.

> I am not suggesting changing the way that the vast majority of UNIX
> utilities and user programs currently look at files, nor suggesting
> any changes to them. I am suggesting that we give a data-handle, if
> you will, for those programs and utilities which care to use the
> "attributes". There is no loss of performance, no restrictions placed
> on file usage, and very small extra disk space used.

Wrong.  If, for example, you write files with "FORTRAN carriage control"
differenly from UNIX text files (with embedded ASCII control characters for
carriage control), current UNIX utilities will not be able to read those
files, *unless you change them* - which you say you are not suggesting.

> I think that you folks who are having a look at creating UNIX utilities
> which can do serious data manipulation, 

Plenty of UNIX utilities can do that already.

> read magtapes from "foreign" operating systems and munge it (without
> having to read the ANSI magtape header files by hand),

Such programs exist for UNIX - yes, they have to read the magtape header by
hand, but so what?  Unless you modified "grep", you couldn't do

	grep mumble /dev/mt0/frobozz.c

(or however you'd have "grep" read file "frobozz.c" on a magtape) without
changing "grep" to understand the ANSI record format.  Even if you did
modify "grep" (and the operating system, so that you could treat a magtape
as a file-structured device using ANSI labels), you probably wouldn't want
to.  You'd probably want to extract the file first - using a program to
extract files from a tape; that program would be the only program on the
whole system which had to know anything about ANSI labels, etc.

> or write utilities which can look at different files without knowing a
> priori the file format,

Why would you want a utility that could work on text files and FORTRAN
binary files?  What operations on such files (other than copy, move, etc.)
would be common to both kinds of files?  You hardly want to print a FORTRAN
binary file the same way you print a text file, or scan through a FORTRAN
binary file with "grep", or...  Nor would you want to be able to feed a text
file to a FORTRAN program that expects binary files (I doubt you can do that
with VMS or any other operating system, either).

Most of the UNIX programs that use "simple" access methods (i.e., reading
byte streams) have no interest in reading anything but text files.  The
other programs read structured files through a user-mode I/O package; that
package would have no problem reading a file header placed at the beginning
of the file.  "cp", since it copies bytes, not records, would copy those
structured files or any other collection of bytes you want to put into a
files; the same holds true for "tar", "cpio", etc..  No program which
expects to read text files would be likely to want to read a structured file
like that.

As for FORTRAN vs. ASCII carriage control, seems to me I remember a DEC
operating system called RT-11 which used ASCII carriage control for all its
text files, and it seemed to support FORTRAN...

In short, lots of us who *are* familiar with FORTRAN files and ANSI tapes do
*not* recognize UNIX as having any of the problems you're talking about -
but all this has been said before; you've provided no new arguments in favor
of adding attributes like that to UNIX files.

	Guy Harris