File; Archive; and File-System theory (was: libraries)

[Robert C. White Jr.]

in article <13300 at ncoast.UUCP>, allbery at ncoast.UUCP (Brandon S. Allbery) says:
> btw, your "ar doesn't
> preserve file-ness because it archives the contents" argument falls flat on
> its silly face when applied to tar or cpio

It does not "fall flat on it's face when applied to cpio or tar" because
these two file types also do not preserve the "file"ness of that which
they archive.

Saying hat a [ .a file | cpio output | tar output ] is a "group of
files" is incorrect.  All these things a are relitavely portable way of
storing the "contents of" zero or more system objects (files).  It is
part of the nature of "contents of" that the "nature" of the object be
preserved, and hence owner id number et. al. are stored with the data.
a sufficiently intelegent program ( ar | cpio | tar | ld | whatever ) can
take that information and recreate a "file" which is congruent to the
original, or extract the desired data.

If you say "That is the same thing" you are wrong. 

Having 8floz. of frozen concentraited orange juice, a pitcher, a cold
water tap, and a spoon (for stiring) IS NOT the same thing as having a
gallon of orange juice from concentrate in the fridge and both are
different than having a glass of orange juice.  Granted, the first group
allows you to make the second and the second allows you to have the
third, but each state is different.  If you got innovative enough you
could even go stright from the first state to the third directly
(parital extraction).  IF you don't understand the difference between
these states, or you miss the value of the distinction, go ask an invalid.

having an archive and an archive tool ( .a & ar, image & cpio, or
image & tar ) is NOT the same thing as having the files you could
create with one of those pairs.  If you are creative enough, and have a
compiler or text editor, you could make a custom tool (via. compiler ;-) to
or manually (via. editor ;-) extract the data you desire, but doing so (or
even logically proving that you could do so) doesn't make the segments
of the archive "files" in a system-object sense.

A system object "file" by definition cannot contain another "file."  It
may contain refrences to other system objects (called directories); 
it may contain the information and data necessary to create a file
(called archives);  and it may even contain instructions, and optionally the
information and/or data also, necessary to create a file (called a program). 
In the more global sense a file may even simbolically represent other
system objects or services (device special, symbolic links, driver hooks, etc.).

The one exception to this files-don't-contain-filess rule is the raw
device which refers to the partition which contains a file system.  The
reason that this does not violate the general definition is that
those "raw device special" files are symbolic refrences to ("alien"
might be a good word here) quantities that the operating system
requires.  You could consider a "raw device" as containing an archive of
sorts.  The case, however, is so spesific that a fill-in term was invented
to bridge the concepts of device, archive, and service as they apply to
this special case.  That term is "file system." ;-)

If you were to alter an archive sufficinetly to make it useful as a file
system it wouldn't be an "archive" any more, you wouldn't need the
archiving tool (because normal file system tools and functions would then
apply), and it wouldn't be portable (unless it really caught on ;-).

Rob.

P.S.  I looked my key terms up, and checked my (aledged ;-) facts and
usages in refrences which I deemed "sufficiently authoritative" for this
forum.  So there Pphhththtttttt... ;-)