more on file \"attributes\"

[Daniel R. Levy]

jcampbell at mrfort.DEC (Jon Campbell) <3398 at decwrl.UUCP>:

>What many users have suggested is that I put a "file header" at the
>beginning of each file. This seems like a reasonable approach, except
>that existing FORTRANs do not put such cruft at the beginning of files
>now. So we have a skew problem. What I was suggesting, though it might
>have not been clear, is an "invisible" file header, one which you look
>at in a slightly different way than the real data (the bytes in the file).
>Perhaps this could be by using a negative byte address in the file, perhaps
>some other way. I'm not particularly interested in the way it might be done,
>except that it cannot be part of the actual data and it cannot be a separate
>file.

>There are many such operating systems (which have file information in
>invisible or hidden headers) around, such as the ATEX text-processing
 
>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.
> 
>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.
> 

Some comments.  One of the beauties of Unix files (the ordinary kind) is that
you can deal with them without having to worry about anything EXCEPT the "act-
ual data" in them.  ANY scheme which uses files which contain information which
is out of the "actual data" is going to add new requirements to programs which
manipulate files.  This has been beaten to death on the net but is a very valid
point.  Special features not in the actual data would be lost the moment the
file was manipulated by a "dumb" command, like "cat" or "vi" or "ed" or
(name your favorite command).  All "cp" does now is to read in the data of its
input files, character by character, and spits it out to the output files.
It would have to be more sophisticated, like VMS COPY, to know that it should
open a file with special attributes.  This would be slower running.  cp does
not now copy the time of creation of the first file to the second one, also,
so your assertion above (that the file creation time is transferred from the
original to the copied file) is mistaken.  For that matter, the file size is
not directly transferred either (it is determined by the data which
is actually copied, and under ordinary circumstances it is no surprise that
it is the same as for the original file).

Skews against other FORTRANs?  While I admit that a header would generate a
skew against the present "f77", remember any attempt to transfer files with
attributes from one operating system to another has got to deal up front with
those attributes.  What about, for instance, trying to transfer VMS files with
special Fortran carriage control attributes to an IBM system?  Even disregar-
ding the ASCII-EBCDIC skew, the interface program is expected to know about
the special quirks of files on both systems.  The header in a Unix Fortran out-
put file would just be treated as another such quirk when transferred to an-
other operating system.

It probably would be a good idea, however, to only add headers to output files
which are intended to contain a special attribute, such as carriage control or
binary files.  And of course it would be desirable to determine what kind of
file is being written into (it would be silly to put a header out to a terminal
or a pipe, so detection of that kind of redirection on a logical unit would
cause carriage control attributes to be translated into the standard ASCII
control characters in that case).

There seems to be no easy answer.  I stand firm with those, however, who say
don't tamper with the Unix way of storing files.  At least 99.99% of all the
programs running on Unix machines will be "c" programs, which don't need the
overhead of having to account for the special "fortran" stuff whenever they
process files.  (Sorry, pascal and lisp programmers, I should lump you in
with the "c" people.)

Enough rambling for now.  I doubt if I've said anything anyone else hasn't.
-- 
 -------------------------------    Disclaimer:  The views contained herein are
|       dan levy | yvel nad      |  my own and are not at all those of my em-
|         an engihacker @        |  ployer, my pets, my plants, my boss, or the
| at&t computer systems division |  s.a. of any computer upon which I may hack.
|        skokie, illinois        |
|          "go for it"           |  Path: ..!ihnp4!ttrdc!levy
 --------------------------------     or: ..!ihnp4!iheds!ttbcad!levy