more on file \"attributes\"

[Chuck Hedrick]

In article <3398 at decwrl.UUCP> jcampbell at mrfort.DEC (Jon Campbell) writes:
>Well, my mailbox runneth over with mail telling me how I've struck
>at the heart of UNIX by suggesting file attributes. I think perhaps
>I have presented the problem (and its possible solution) in the wrong
>light.
> 
>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. 

I would much rather have a skew problem between f77 and your Fortran
than between Unix and your new OS (whatever you choose to call it).
Even if you hid your attributes somewhere, it is unlikely that your
new Fortran would be compatible with the old.  One assumes that new
programs would no longer specify the file attributes in OPEN.  (I
mean, why bother adding all these attributes in the file if the user
is still going to have to specify them in his program.)  A program
that failed to specify the attributes could no longer work when
compiled under the old Fortran.  Futhermore, it is likely that your
new Fortran would support a wider variety of file and record
organizations than the old one.  So in fact the amount of
compatibility that would be possible is minimal.  For the cases where
it is possible, one could have a utility that strips or adds the
headers.  You could also have an OPEN parameter that said not to
create a header for new files, and your Fortran could be trained to
read files that did not have a header, as longer as the user specified
enough of the attributes explicitly in OPEN.

Let's look at some of the costs of making the change that you propose:

1) You are going to have to hide the information either in the inode,
or in some sort of negative file address.  Changing the file system to
allow this will make it incompatible with other Unix file systems.
Probably you will want to put it in a negative file address, or a
special block accessible only through some special system call Adding
it to the inode would cause the size of the inode to increase, thus
penalizing everyone (in disk space used) even if they don't use the
feature.

2) You will have to change the dump, restore, and tar to save this
information on tapes and restore it.  I trust you want your attributes
to go onto backup tapes (dump and restore) and for it to be possible
to move this information with a file when you take the file to a
different system (tar).  A new switch will have to be added to tar
to allow you to suppress this information, in order to avoid confusing
systems that don't understand it.  Tapes produced on your system would
in general not be compatible with other systems unless this switch
is used.

3) You will have to change cp, mv, and various other utilities.  Users
are accustomed to the fact that when they copy a file, the copy is
the same as the original.  This would no longer be the case if copying
stripped off attribute information.

4) The network protocols used for FTP and rcp would have to be
extended to allow attribute information to be sent over the net.  Many
sites depend upon use of the network to keep various systems in sync
with each other.  They would not be able to tolerate having attribute
information disappear when the file is moved.

5) Programs that depended upon having attributes would not work with
I/O over pipes or other kinds of streams.  This could be a serious
restriction for some kinds of program.  Indeed you would be breaking
the device-independence of your I/O system, since it would be
impractical to have hidden attributes for any device other than disk
or its equivalent.

These are fairly serious costs, in implementation time, compatibility
with other Unix systems, and increased complexity of the file system.
It is very unlikely that many (any?) customers would want to pay these
costs.  I think these costs are clearly larger than any Fortran
version skew, particularly since there are ways to get around the
Fortran skew.

You might be interested that the same issues came up on the DEC-20
when RMS was implemented there.  They chose to put the RMS file
attribute information in a header at the beginning of the file.  I
certainly don't know why that choice was made, but the costs of
modifying TOPS-20 would have been similar to those of modifying Unix
to support attributes.

I urge you to talk to some of us in person before proceeding with
anything like what you have proposed to do.  The opposition to your
suggestion is not based on misunderstanding, nor does it indicate a
lack of sympathy with your goals.  Any change to the simplicity of the
file model *does* strike at the heart of Unix.