rwhite@nusdhub.UUCP (Robert C. White Jr.) (12/30/88)
in article <13300@ncoast.UUCP>, allbery@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... ;-)
allbery@ncoast.UUCP (Brandon S. Allbery) (01/05/89)
As quoted from <1286@nusdhub.UUCP> by rwhite@nusdhub.UUCP (Robert C. White Jr.): +--------------- | 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 ;-). +--------------- You've just proved that if I put "ar" in the FSS of my SVR3.1 box at work, I'd have successfully made it into a file system instead of an archive. On a V7 system, a V6 filesystem is treated as a file -- yes, an *archive*. (See the old V7 manuals.) Does this magically make it *not* a file system? Of course not. It's just not a *native* file system -- which is why System V.3 has the FSS, so that non-native filesystems can be *made* native. There is effectively only one difference between file systems and archives, we seem to be agreed; however, you consider it to be an absolutely fundamental difference, whereas I consider it to be minor and trivial. ++Brandon -- Brandon S. Allbery, comp.sources.misc moderator and one admin of ncoast PA UN*X uunet!hal.cwru.edu!ncoast!allbery ncoast!allbery@hal.cwru.edu comp.sources.misc is moving off ncoast -- please do NOT send submissions direct Send comp.sources.misc submissions to comp-sources-misc@<backbone>.
rwhite@nusdhub.UUCP (Robert C. White Jr.) (01/10/89)
in article <13310@ncoast.UUCP>, allbery@ncoast.UUCP (Brandon S. Allbery) says: > There is effectively only one difference between file systems and archives, > we seem to be agreed; however, you consider it to be an absolutely > fundamental difference, whereas I consider it to be minor and trivial. Good enough. (too much o.s. theory I guess) My inital point was simply that at no point do you have a "file that contains other files." After several e-mail exchanges I have altered this to "At no time do you have a File which contains other Files within a single frame of refrence." e.g. you either open all of it with open() or you mount it and open parts with open() but you dont ever open it with open() and then open it's parts with open() based soley on what you retreived from that open, without invoking some File-System-Switch-or-whatever change of context. -- A necessary, but usually moot, distinction. Rob. "Convoluted? My thinking is not convoluted; it simply tends to vary between multi-polar states whose description, in terms of spacial relativity, would produce a plane-segment-tiled model of a landscape which may, or may not be, Flat (in some areas ;-)."