Usenet 1994 October/usenetsourcesnewsgroupsinfomagicoctober1994disk2.iso/std_unix/volume.11

Internet Message Format | 1987-07-18 | 261KB

From jsq  Sun Mar 29 12:31:21 1987
Posted-Date: 24 Mar 87 15:15:04 GMT
Received-Date: Sun, 29 Mar 87 12:31:21 CST
Received: by sally.utexas.edu (5.54/5.51)
    id AA21033; Sun, 29 Mar 87 12:31:21 CST
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: comp.std.unix Volume 11 [Reposting.  -mod]
Keywords: contents, index, summary, statistics
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 24 Mar 87 15:15:04 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Moderator, John Quarterman)

This is the first article in Volume 11 of comp.std.unix (formerly
known as mod.std.unix).

The USENET newsgroup comp.std.unix is also known as the ARPA Internet
mailing list [e-mail].  It is for discussions of
UNIX standards, particularly the IEEE 1003.1 POSIX Trial Use Standard.
The moderator is John S. Quarterman, who is also the institutional
representative of the USENIX Association to the IEEE P1003 Portable
Operating System for Computer Environments Committee (commonly known
as the UNIX Standards Committee).

Submissions-To:    ut-sally!std-unix    or [e-mail]
Comments-To: ut-sally!std-unix-request    or [e-mail]
UUCP-Routes: {gatech,harvard,ihnp4,seismo,pyramid,sequent}!ut-sally!std-unix

Permission to post to the newsgroup is assumed for mail to std-unix.
Permission to post is not assumed for mail to std-unix-request,
unless explicitly granted in the mail.  Mail to my personal addresses
will be treated like mail to std-unix-request if it obviously refers
to the newsgroup.

Archives may be found on sally.utexas.edu.  The current volume may
be retreived by anonymous ftp (login anonymous, password guest)
over the ARPA Internet as ~ftp/pub/comp.std.unix.  This is Volume 11.
Volumes 1-10 are filed under the old newsgroup name, mod.std.unix,
as ~ftp/pub/mod.std.unix.v1, ~ftp/pub/mod.std.unix.v2, etc., through
~ftp/pub/mod.std.unix.v10.  Volume 3 contains the AT&T public domain
getopt(3).  Volume 10 is a special index volume that catalogs Volumes 1-9.

These volumes are strictly for administrative convenience.
Paper copies of them get delivered to the P1003 committee chair
from time to time and several members of the committee follow
the newsgroup on-line.

Also, paper copies will soon be available from the office of the
USENIX Association, in support of the Institutional Representative
from USENIX to the IEEE P1003 committee.  Selection will be by
whole volumes only, not by specific articles.  This service will
be available when sufficient disk space is added to USENIX equipment
in the next few months.

        USENIX Association
        P.O. Box 7
        El Cerrito, CA 94530
        415-528-8649
        {ucbvax,decvax}!usenix!office

The archives have been somewhat cleaned up in the process of indexing
them.  Irrelevant mail headers have been deleted and "From " (not "From:")
lines in text articles have been escaped or removed to avoid confusing
mail reading programs.  An extra header, "Draft-9:", has been added to
contain the index references by section of 1003.1 Draft 9 or related
topic.  It is hoped that these changes, together with the access
information in Volume 10, will make the archives more useful.

Finally, remember that any remarks by any committee member (especially
including me) in this newsgroup do not represent any position (including
any draft, proposed or actual, of a standard) of the committee as a
whole or of any subcommittee unless explicitly stated otherwise
in such remarks.

UNIX is a Registered Trademark of AT&T.
POSIX is a Trademark of IEEE.
IEEE is a Trademark of the Institute of Electrical and Electronics
    Engineers, Inc.

PS:  If this article was garbled in transmission to you, that probably
means it passed through a host still running B news 2.10, which doesn't
understand moderated newsgroup names that don't start with "mod.".
You should examine the Path: header, try to determine which host it is,
and ask them to upgrade to 2.11.

Volume-Number: Volume 11, Number 1

From jsq  Fri Apr  3 22:01:06 1987
Posted-Date: 2 Apr 87 20:20:23 GMT
Received-Date: Fri, 3 Apr 87 22:01:06 CST
Received: by sally.utexas.edu (5.54/5.51)
    id AA01857; Fri, 3 Apr 87 22:01:06 CST
From: Philip Kos <[e-mail]>
Newsgroups: comp.std.unix
Subject: Submission for comp-std-unix
Keywords: POSIX standard outrageous claim
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Philip Kos)
Organization: Johns Hopkins Hospital
Date: 2 Apr 87 20:20:23 GMT
Apparently-To: std-unix-archive

>From: [e-mail] (Philip Kos)

I realize that it's been awhile since I made it all the way to comp.std.unix
in my list of newsgroups, so if I've missed something that makes this all
blow back in my face, would someone please correct me?

I registered for UniForum back in January (actually I *was* registered by
one of our division secretaries, along with everyone else in the division,
although I never showed up there), and since then have been getting pounds
of junk mail relating to using Unix in an MIS/DP sort of environment.  Well,
the most recent piece of trash to come my way was an offer for three free
complimentary issues of a magazine called _Unix_in_the_Office_, apparently
produced by "Patricia Seybold's Office Computing Group".  I'm not really
interested in anything the magazine has to offer, so I was about to throw
it out when the word "Standard" in the flyer attracted my eye.  I read the
paragraph and found the following claim:

    ".... Posix is a well-supported vendor-independent standard...."

Golly, I thought to myself.  Have they sped up the procedure that much?
It seems like just a few months since I recall it going into the trial use
period... have I missed the IEEE announcement, and all the discussion
which must have accompanied it?  Or are these people just talking through
their hats?

There are a number of other claims in the flyer which seem to stretch my
capacity for belief, so I am assuming that these people are talking through
their hats.  Also, the three free issues seem to turn into a $495 (and no,
I didn't leave a decimal point out of that number) annual subscription rate
if you don't cancel fast enough.  All in all, this looks like a Fast Buck
production, and I don't think I'd trust anything I read in it farther than
I can spit a weasel.  But it *has* been awhile since I was following this
group, so I figured I'd ask before I go shooting my mouth off about how
these people are talking through their hats...

Can anyone help me out here?



--
                              ...!decvax!decuac -
Phil Kos                                          \
The Johns Hopkins Hospital    ...!seismo!mimsy  - -> !aplcen!osiris!phil
Baltimore, MD                                     /
                              ...!allegra!mimsy -


[ The above opinions are those of the submittor.  Readers, please remember
that this is a technical newsgroup when responding (i.e., no flames, please).

The Working Group hopes to get the Full Use Standard balloted by this
fall (1987).  For the moment, there is only the Trial Use Standard.
-mod ]

Volume-Number: Volume 11, Number 2

From jsq  Mon Apr  6 23:29:12 1987
Posted-Date: 7 Apr 87 04:28:46 GMT
Received-Date: Mon, 6 Apr 87 23:29:12 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA11597; Mon, 6 Apr 87 23:29:12 CDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: Why getpwent but not putpwent?
Summary: POSIX supports application programs, not system administration
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 7 Apr 87 04:28:46 GMT
Apparently-To: std-unix-archive

There's been a bit of discussion on UNIX-WIZARDS as to why POSIX
doesn't include mechanisms for modifying the password database.
I.e., it does include getpwent() to get entries from the database
(without specifying whether the database is kept in a file or not),
but does not include putpwent() or anything like it.

Basically, POSIX is intended to promote portability of application
programs.  System administration functions (including at least just
about anything that requires super-user privileges) are almost by
definition not ordinary application programs, and the methods needed
to implement them will likely vary radically from underlying system
to system, anyway.

As another example, POSIX includes getgroups(), but not setgroups().

The Full Use Standard will have an appendix ``Rationale and Notes''
to explain things like this.  If you have a favorite nit to pick,
obscure section, omission, or ambiguity in the Trial Use standard,
please submit it to this newsgroup (mail to [e-mail])
or, if you just want it considered for the Rationale, but not posted,
send it to the moderator (mail to [e-mail]).
Sally.utexas.edu is the same as ut-sally on UUCP mail network.

Volume-Number: Volume 11, Number 3

From jsq  Tue Apr 14 17:48:54 1987
Posted-Date: 14 Apr 87 22:48:41 GMT
Received-Date: Tue, 14 Apr 87 17:48:54 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA21480; Tue, 14 Apr 87 17:48:54 CDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix,comp.unix.questions,comp.org.usenix
Subject: Access to UNIX-Related Standards
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Moderator, John Quarterman)
Date: 14 Apr 87 22:48:41 GMT
Apparently-To: std-unix-archive

This is the latest in a series of similar mod.std.unix articles.
Corrections and additions to this article are solicited.


Access information is given in this article for the following standards:
IEEE 1003.1 (POSIX), 1003.2 (shell/tools), 1003.3 (verification)
/usr/group working groups on distributed file system, network interface,
    graphics/windows, database, internationalization,
    performance measurements, realtime, and security
X3H3.6 (display committee)
X3J11 (C language)
/usr/group Standard
System V Interface Definition (SVID, or The Purple Book)
X/OPEN PORTABILITY GUIDE (The Green Book)


UNIX is a Registered Trademark of AT&T.
POSIX and IEEE are trademarks of the Institute of Electrical
    and Electronic Engineers, Inc.
X/OPEN is a licensed trademark of the X/OPEN Group Members.


The IEEE P1003 Portable Operating System for Computer Environments Committee
is sometimes known colloquially as the UNIX Standards Committee.
They published the 1003.1 "POSIX" Trial Use Standard in April 1986.
According to its Foreword:

    The purpose of this document is to define a standard
    operating system interface and environment based on the
    UNIX Operating System documentation to support application
    portability at the source level.  This is intended for
    systems implementors and applications software developers.

Published copies are available at $19.95,
with bulk purchasing discounts available.
Call the IEEE Computer Society in Los Angeles

        714-821-8380

and ask for Book #967.  Or contact:

        IEEE Service Center
        445 Hoes Ln.
        Piscataway, NJ 08854

and ask for "IEEE 1003.1 Trial Use Standard" - stock number SH10546.

The Trial Use Standard will be available for comments for a period
such as a year.  The current target for a Full Use Standard is Fall 1987.
IEEE has initiated the process to have the 1003.1 effort brought into
the International Organization for Standardization (ISO) arena.

Machine readable copies of the Trial Use Standard are not and will
not be available.  A machine-readable "representation" of a draft
between the Trial Use and Full Use Standards may be available when
it is ready.

There is a paper mailing list by which interested parties may get
copies of drafts of the standard.  To get on it, or to submit comments
directly to the committee, mail to:

        James Isaak
        Chairperson, IEEE/CS P1003
        Digital Equipment    MK02-2/B05
        Continental Blvd.
        Merrimack, NH      03054-0403
        decvax!jim
        603-884-3692

Sufficiently interested parties may join the working group.

Related working groups are
    group    subject        co-chairs
    1003.2    shell and tools    Hal Jespersen (Unisoft), Don Cragun (Sun)
    1003.3    verification    Roger Martin (NBS), Carol Raye (AT&T)

Inquiries regarding 1003.2 and 1003.3 should go to the same address
as for 1003.1.


The next scheduled meetings of the P1003 working groups are, in 1987:

April    20-21  1003.[23]  King Edward Hotel, Toronto    Host:  IBM
April    22-24  1003.1     "
        (Just before the Canadian UNIX Conference)

June    22-23  1003.1  Seattle (changed from USENIX week in Phoenix to
         give us better working attendance)    No Host yet
June    24-26  1003.[23]

Aug/Sept 31-4   East Coast Probably Washington DC area    No Host yet
 OR Sept 14-18    Boston (Same Time/loc as X3J11)
(Sept 7th is Labor day, and that week is ISO TC97 SC22 meeting in Wash DC)

There is also a balloting group (which intersects with the working group).
This is more difficult.  Contact the committee chair for details.
I will repost them in this newsgroup if there is sufficient interest.

Here are some details from Hal Jespersen regarding P1003.2:

The IEEE P1003.2 "Shell and Utilities" Working Group is developing a
proposed standard to complement the 1003.1 POSIX standard.  It will
consist of

    a shell command language (currently planned to be based on the
    Bourne Shell),

    groups of utility programs, or commands,

    programmatic interfaces to the shell (system(), popen()) and
    related facilities (regular expressions, file name expansion,
    etc.)

    defined environments (variables, file hierarchies, etc) that
    applications may rely upon

which will allow application programs to be developed out of existing
pieces, in the UNIX tradition.  The scope of the standard emphasizes
commands and features that are more typically used by shell scripts or
C language programs than those that are oriented to the terminal user
with windows, mice, visual shells, and so forth.

The group is currently seeking proposals for groupings of commands that
may be offered by implementors.  As groups are identified, command
descriptions will be solicited.  There is no requirement that the commands
be in System V or BSD today, but they should realistically be commands
that are commonly found in most existing implementations.

Meetings are normally held in conjunction with the 1003.1 group and
have a large membership overlap.  Future meetings will generally be held
on the day or two preceding 1003.1.


There are three Institutional Representatives to P1003:  John Quarterman
from USENIX, Heinz Lycklama from /usr/group, and John Loman from X/OPEN.

As the one from USENIX, one of my functions is to get comments from the
USENIX membership and the general public to the committee.  One of the
ways I try to do that is by moderating this newsgroup, comp.std.unix
(formerly known as mod.std.unix).  An article related to this one
appeared in the September/October 1986 ;login: (The USENIX Association
Newsletter).  I'm also currently on the USENIX Board of Directors.
Comments, suggestions, etc., may be sent to

        John S. Quarterman
        TIC
        P.O. Box 14621
        Austin TX 78761
        512-837-7233
        usenix!jsq
For mod.std.unix (comp.std.unix):
Comments:    ut-sally!std-unix-request [e-mail]
Submissions:    ut-sally!std-unix        [e-mail]

The January/February 1987 issue of CommUNIXations (the /usr/group newsletter)
contains a report by Heinz Lycklama on the /usr/group Technical Committee
working groups which met in September 1986.

If you are interested in starting another working group, contact
Heinz Lycklama:

        Heinz Lycklama
        Interactive Systems Corp.
        2401 Colorado Ave., 3rd Floor
        Santa Monica, CA 90404
        [phone]
        decvax!cca!ima!heinz


Here is contact information for /usr/group working groups as taken from
the CommUNIXations article mentioned above.

/usr/group Working Group on Distributed File System:
    Dave Buck
    D.L. Buck & Associates, Inc.
    6920 Santa Teresa Bldg, #108
    San Jose, CA 95119
    [phone]

/usr/group Working Group on Network Interface:
    Gil McGrath
    AT&T Information Systems
    [phone]

/usr/group Working Group on Internationalization:
    Karen Barnes
    Hewlett-Packard Co.
    19447 Pruneridge Ave.
    M/S 47U2
    Cupertino, CA 95014
    [phone], ext 2438

/usr/group Working Group on Graphics/Windows:
    Tom Greene
    Apollo Computer, Inc.
    [phone]

/usr/group Working Group on Realtime:
    Bill Corwin
    Intel Corp.
    5200 Elam Young Pkwy
    Hillsboro, OR 97123
    [phone]

/usr/group Working Group on Database:
    Val Skalabrin
    Unify Corp.
    1111 Howe Ave.
    Sacramento, CA 95825
    [phone]

/usr/group Working Group on Performance Measurements:
    Ram Celluri            Dave Hinant
    AT&T Computer Systems        SCI Systems, Inc.
    Room E15B            Ste 325, Pamlico Bldg
    4513 Western Ave.        Research Triangle Pk, NC 27709
    Lisle, IL 60532            [phone]
    [phone]

/usr/group Working Group on Security:
    Steve Sutton
    Computer Systems Div.
    Gould Inc.
    1101 East University
    Urbana, IL 61801
    [phone]


The X3H3.6 display management committee has recently formed to develop
a model to support current and future window management systems, yet
is not based directly on any existing system.  The chair solicits
help and participation:

        Georges Grinstein
        wanginst!ulowell!grinstein


The Abstract of the 1003.1 Trial Use Standard adds:

    This interface is a complement to the C Programming Language
    in the C Information Bulletin prepared by Technical Committee X3J11
    of the Accredited Standards Committee X3, Information Processing
    Systems, further specifying an environment for portable application
    software.

X3J11 is sometimes known as the C Standards Committee.  Their liaison to
P1003 is

        Don Kretsch
        AT&T
        190 River Road
        Summit, NJ 07901

A contact for information regarding publications and working groups is

        Thomas Plum
        Vice Chair, X3J11 Committee
        Plum Hall Inc.
        1 Spruce Avenue
        Cardiff, New Jersey 08232

The current document may be ordered from

        Global Press
        2625 Hickory St.
        P.O. Box 2504
        Santa Anna, CA 92707-3783
        U.S.A.
        800-854-7179
        [phone] (from outside the U.S., ask for extension 245.)
        TELEX 692 373

who know X3J11 as X3.159.  The price is $65.


The /usr/group Standard is a principal ancestor of P1003.1, X/OPEN,
and X3J11.  It may be ordered for $15.00 from:

        /usr/group Standards Committee
        4655 Old Ironsides Drive, Suite 200
        Santa Clara, California 95054
        [phone]


The System V Interface Definition (The Purple Book, or SVID).
This is the AT&T standard and is one of the most frequently-used
references of the IEEE 1003 committee.

        AT&T Customer Information Center
        Attn:  Customer Service Representative
        P.O. Box 19901
        Indianapolis, IN 46219
        U.S.A.

        800-432-6600 (Inside U.S.A.)
        800-255-1242 (Inside Canada)
        317-352-8557 (Outside U.S.A. and Canada)

    System V Interface Definition, Issue 2
    should be ordered by the following select codes:

    Select Code:    Volume:        Topics:
    320-011        Volume I    Base System
                    Kernel Extension
    320-012        Volume II    Basic Utilities Extension
                    Advanced Utilities Extension
                    Software Development Extension
                    Administered System Extension
                    Terminal Volume Interface Extension
    320-013        Volume III    Base System Addendum
                    Terminal Interface Extension
                    Network Services Extension
    307-131        I, II, III    (all three volumes)

The price is about 37 U.S. dollars for each volume or $84 for all three.
Major credit cards are accepted for telephone orders:  mail orders
should include a check or money order, payable to AT&T.


The X/OPEN PORTABILITY GUIDE (The Green Book)
is another reference frequently used by IEEE 1003.

The X/OPEN Group is "Ten of the world's major information system
suppliers" (currently Bull, DEC, Ericsson, Hewlett-Packard, ICL,
NIXDORF, Olivetti, Philips, Siemens, Unisys, and AT&T) who have
produced a document intended to promote the writing of portable
facilities.  They closely follow both SVID and POSIX, and cite
the /usr/group standard as contributing, but X/OPEN's books
cover a wider area than any of those.

The book is published by

        Elsevier Science Publishers B.V.
        Book Order Department
        P.O. Box 1991
        1000 BZ Amsterdam
        The Netherlands

and distributed in the U.S.A. and Canada by:

        Elsevier Science Publishing Company, Inc.
        52 Vanderbilt Avenue
        New York, NY 10017
        U.S.A.

There are currently five volumes:
    1) System V Specification Commands and Utilities
    2) System V Specification System Calls and Libraries
    3) System V Specification Supplementary Definitions
    4) Programming Languages
    5) Data Management

They take a large number of credit cards and other forms of payment.

Volume-Number: Volume 11, Number 4

From jsq  Tue Apr 14 17:48:54 1987
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: Access to UNIX-Related Standards
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Moderator, John Quarterman)
Date: 14 Apr 87 22:48:41 GMT
Apparently-To: std-unix-archive

Number 5 got lost somehow.

Volume-Number: Volume 11, Number 5

From jsq  Mon Apr 27 22:29:32 1987
Posted-Date: 26 Apr 87 10:27:41 GMT
Received-Date: Mon, 27 Apr 87 22:29:32 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA18593; Mon, 27 Apr 87 22:29:32 CDT
From: Doug Gwyn  <[e-mail]>
Newsgroups: comp.std.unix
Subject: new directory library
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 26 Apr 87 10:27:41 GMT
Apparently-To: std-unix-archive

[ I found this in comp.unix.wizards. -mod ]

I have just sent a totally revamped public-domain implementation
of a set of (nearly) POSIX-compatible directory access routines
to mod.sources.  It is intended to be the definitive implementation.
Check the NOTES file bundled with the sources for more information.

Volume-Number: Volume 11, Number 6

From jsq  Sat May  9 13:57:22 1987
Posted-Date: 9 May 87 18:57:09 GMT
Received-Date: Sat, 9 May 87 13:57:22 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA05992; Sat, 9 May 87 13:57:22 CDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: alias problem fixed
Message-Id: <[e-mail]>
Date: 9 May 87 18:57:09 GMT
Apparently-To: std-unix-archive

There was a problem with the std-unix and std-unix-list aliases
which caused all mail to them to get lost.  This evidently was
the state of both aliases for about a month.  That period happened
to coincide with the newsgroup name change, to which I attributed
the lack of traffic.  I discovered and fixed the problem the other day.

So, if you've submitted something in the last month or so, I haven't
been ignoring you, I just didn't get it.  Please resubmit.

For that matter, those of you who haven't submitted anything, please
feel free to do so.

Volume-Number: Volume 11, Number 7

From jsq  Sat May  9 14:12:04 1987
Posted-Date: 9 May 87 19:11:53 GMT
Received-Date: Sat, 9 May 87 14:12:04 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA06347; Sat, 9 May 87 14:12:04 CDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: tar or cpio?
Message-Id: <[e-mail]>
Date: 9 May 87 19:11:53 GMT
Apparently-To: std-unix-archive

Section 10 of the POSIX Trial Use Standard (and of the current draft)
describes a data interchange format based on the tar program.  The P1003.1
Working Group has recently received two related proposals regarding that
section:  one to add cpio format (including old-style, non c option format);
the other to replace the tar format with cpio format.  It was also proposed
in the latest Working Group meeting to drop section 10 altogether and let
P1003.2 handle the issue.

As the moderator of this newsgroup, I solicit comments about what should
be done with section 10.

As a Working Group member, I will take such comments into account when
I submit a proposal in a few weeks.  If there is sufficient interest,
I will post an outline of that proposal in the newsgroup (as myself,
rather than as the moderator).  I can also post the already-submitted
proposals.

Volume-Number: Volume 11, Number 8

From [e-mail] Sun May 10 02:30:14 1987
From: Guy Harris <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar or cpio?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Guy Harris)
Date: 10 May 87 07:27:25 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Guy Harris)

> As the moderator of this newsgroup, I solicit comments about what should
> be done with section 10.

One thing that should not be done, under any circumstances, is to
replace "tar" with "cpio" - *especially* if it includes the old
non-"-c" form.  The non-portable form is completely useless for
moving data between systems with different byte orders unless you
have a clever "cpio" that figures out that the byte order is
backwards and undoes the damage.

I discovered this when trying to read a "cpio" tape made on a VAX in
the old format; no combination of "cpio" byte-swapping options and
"dd conv=swab" would help.  I finally ended up fixing our "cpio" to
do the aforementioned look-at-the-header-and-undo-the-damage stuff.

The X/OPEN standard uses "cpio".  The rationale given exhibits a
distressing degree of incompetence:

    If an exchange mdeium is to be read on a target machine that
    is architecturally different from the source machine,
    problems may arise concerning the ordering of bytes within a
    word and words within a long word (see the portability guides
    in Part III).  These can easily be handled when using "cpio"
    as an exchange utility, while with "tar" it may be a little
    more difficult.

Now, I will first note here that the *only* time I had a problem
moving "tar" tapes between machines was when I had to move things to
a Plexus.  The problem was *not* that the machines had different byte
orders; the problem was that the Plexus had a typical brain-damaged
Multibus tape controller that swapped bytes when it transferred data
to and from memory.

"cpio" would not have made this any easier; the System III
byte-swapping option did not swap the bytes on *all* blocks read, but
just swapped the bytes on data blocks and in file names.  The intent
here was clearly that you would read a tape written on a machine with
a different byte order by doing something like

    dd if=/dev/rmt0 conv=swab | cpio -ids

"dd" would swap everything; "cpio -s" would un-swap everything but
the binary data in the header.  (We pause to note that merely
swapping the binary data in the header would be much more efficient,
especially given that "dd" is somewhat of a pig.)  This works, but is
less than wonderful.  (And it doesn't solve the problem with the
Plexus; to solve that you just stick the "dd" in front of "cpio" and
don't bother with "-s" at all.)

The System V "cpio" byte-swapping and word-swapping options work
*only* on data blocks; they have no effect whatsoever on binary data
in the header or on file names.  This means that the trick that
worked with the System III "cpio" wouldn't work at all - and the
problem with the Plexus still isn't fixed, if that was the intent.
The S5 options are useless for old-style non-"-c" tapes.  They are of
some use with "-c" tapes - but only if all the files on the tape
consist solely of "short"s or "long"s, since the data in the data
blocks are all byte-swapped or word-swapped in the same fashion.
Most files I tend to put on or extract from "cpio" tapes are text
files, which obviously need no swapping.

In short, the arguments offered by X/OPEN in favor of "cpio" are
completely bogus.

Now for the arguments against "cpio" format:

    1) It is somewhat more UNIX-specific, in that the "mode"
       field of the "stat" structure is written out numerically.
       POSIX does not specify required numeric values for this
       field.  "tar" indicates the file type with a standard
       symbolic code, so you can read "tar" tapes even if the
       machine on which the tape was written and the machine on
       which it is being read do not have the same values for
       this field.

    2) It does not handle hard links particularly elegantly.
       "cpio" knows nothing of files with multiple hard links
       when it writes a tape; if it is told to write "foo" and
       "bar" to the tape, and they are both hard links to the
       same file, it writes two copies of this file to the tape.
       The hard links are established when the tape is read.
       If the files appear on the tape in the order "foo" and
       then "bar", "foo" will be read in first.  Once "bar" has
       been read in, "cpio" will check to see if it has already
       read in a file with the same dev/inumber value.  If so, it
       will delete "bar" and make a hard link to "foo" called
       "bar".

    3) It is less common.  Almost all UNIX systems that support
       "cpio" also support "tar"; many UNIX systems that support
       "tar" do not support "cpio".

    4) POSIX has already chosen "tar" format; why should it
       change horses in midstream, especially given that the new
       horse is lame and, despite the claims made by the person
       selling the horse, is not capable of pulling any heavier
       loads than the existing one?

Anyway, I'll have to dig up the proposal made to POSIX that "cpio"
supplement or replace "tar" and cast a very strong "no" vote citing
the above.

Now, as for the proposal for handing the whole thing off to P1003.2 -
I have some inclination to support this.  It could, in some ways, be
considered neither part of the scope of P1003.1 nor of P1003.2, but
to be a separate standardization topic entirely.  However, if I had
to choose which of the two items - C-language binding to OS
system call and library functions, or command-language functions -
the data interchange standard belonged to, I'd vote in favor of the
latter.  There is no library of functions for reading or writing
"tar" tapes, but there is a command (namely, "tar") for reading and
writing them, so I think it belongs in that category - especially
given that Section 10 currently says "A conforming system shall
implement a user utility..." which really sounds a lot more like
a P1003.2 requirement than a P1003.1 requirement.

Volume-Number: Volume 11, Number 9

From jsq  Sun May 10 23:26:37 1987
Posted-Date: 11 May 87 01:44:29 GMT
Received-Date: Sun, 10 May 87 23:26:37 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA02187; Sun, 10 May 87 23:26:37 CDT
From: Charles Hedrick <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar or cpio?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Charles Hedrick)
Date: 11 May 87 01:44:29 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Charles Hedrick)

Since tar exists (as far as I know) on all Unix systems, and cpio only
on ATT ones, tar seems like the best choice for portable use.
Obviously any real POSIX will have both tar and cpio, but why not
leave the standard at tar?  (Note that I haven't read the POSIX
standard, so all I know about the question is what you mentioned in
your note.  I'm responding as if the choice is between the existing
tar or cpio programs.  If this is a new facility that will require a
new program to be written, then I have no comment.)

[ The format in POSIX is upwardly compatible with existing tar programs.
The format proposed for cpio is that of the current cpio program.  -mod ]

By the way, what ever happened about job control?  I recall some
discussion, but not the final resolution.  I had hoped that POSIX
would manage to get a few BSD features into general circulation.
Clearly from the end user's point of view, job control is the one most
important thing missing from System V.  (Actually networking is more
important, but it's not clear whether that is the sort of thing POSIX
should be concerned about.)

[ Job control (the HP proposal) is in the current draft.  Networking
is outside the scope of P1003.1, but there is a /usr/group Technical
Committee addressing the subject with the intention of eventually
providing input to an appropriate IEEE Working Group.  -mod ]

Volume-Number: Volume 11, Number 10

From jsq  Sun May 10 23:47:40 1987
Posted-Date: 11 May 87 04:47:29 GMT
Received-Date: Sun, 10 May 87 23:47:40 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA02477; Sun, 10 May 87 23:47:40 CDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: tar or cpio?
Message-Id: <[e-mail]>
Refernces: <[e-mail]>
Date: 11 May 87 04:47:29 GMT
Apparently-To: std-unix-archive

There have been three documents submitted to the IEEE P1003.1
Working Group recently regarding section 10:

N.043    April 22 1987    ``X/OPEN Proposals to IEEE P1003.1,'' X/OPEN Group,
Section 3.25, ``Data Interchange format.''

N.048    April 15, 1987    ``a proposal for a cpio format to be added to
Chapter 10,'' Lorraine C. Kevra, AT&T.

N.064    April 23, 1987    ``Comments on 1003.1 N.048,'' Dominic Dunlop.

They're about a page apiece.  I may feel energetic enough to type them in.

Volume-Number: Volume 11, Number 11

From jsq  Mon May 11 00:03:31 1987
Posted-Date: 11 May 87 04:05:44 GMT
Received-Date: Mon, 11 May 87 00:03:31 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA02698; Mon, 11 May 87 00:03:31 CDT
From: Doug Gwyn <[e-mail]>
Newsgroups: comp.std.unix
Subject: tar or cpio?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (VLD/VMB)
Date: 11 May 87 04:05:44 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Doug Gwyn)

Let's get the 1003.1 standard adopted and worry about perfection later.

In the real world one HAS to have a working "tar" if one exchanges files
with many random UNIX sites, even if "cpio" might be better technically.

Any proposal for CPIO format that is system-dependent ("old cpio")
rather than portable ("new cpio") should be rejected out of hand.

1003.2 should probably include the "cpio" utility, which has many uses
besides tape archives.  1003.1 should stick to "tar" for tape archives,
or remove that section altogether.

I would prefer to remove tape archive format altogether from what is
supposed to be a program/system interface specification (1003.1).  There
simply isn't a single universal interchange medium anyway (not every
system has 1/2" magtape, for example).

Volume-Number: Volume 11, Number 12

From jsq  Mon May 11 00:30:42 1987
Posted-Date: 11 May 87 05:30:31 GMT
Received-Date: Mon, 11 May 87 00:30:42 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA03147; Mon, 11 May 87 00:30:42 CDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: tar or cpio?  N.043
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: 11 May 87 05:30:31 GMT
Apparently-To: std-unix-archive

N.043    April 22 1987    ``X/OPEN Proposals to IEEE P1003.1,'' X/OPEN Group,
Section 3.25, ``Data Interchange format.''

POSIX c 10

POSIX describes a new data interchange format known as *ustar*.
The XVS has adopted the use of *cpio -c*, a format which is already
widely accepted and in common use.

X/OPEN sees no reason to define a new format which will require
implementaion by all supliers and which will significantly reduce
the usability of media in this format in an environment where certain
systems do not support the new format.

X/OPEN has published details of the cpio header format, see *cpio(4)*
in the XVS, the cpio utility *cpio(1)* and also the hardware requirements
for floppy disk and magnetic tape, *sct(7)* and *XVS SOURCE CODE TRANSFER*
in Volume 3.  These definitions are in the public domain.

X/OPEN proposes that POSIX drops the new *ustar* in favour of *cpio*.

Volume-Number: Volume 11, Number 13

From jsq  Mon May 11 00:50:18 1987
Posted-Date: 11 May 87 05:50:10 GMT
Received-Date: Mon, 11 May 87 00:50:18 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA03339; Mon, 11 May 87 00:50:18 CDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: tar or cpio?  N.048
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: 11 May 87 05:50:10 GMT
Apparently-To: std-unix-archive


N.048    April 15, 1987    ``a proposal for a cpio format to be added to
Chapter 10,'' Lorraine C. Kevra, AT&T.

Secretary, IEEE Standards Board:

The attached is a proposal for a cpio format to be added to Chapter 10
(Data Interchange Format) of the POSIX Standard.

                        Lorraine C. Kevra

NAME
    cpio - format of cpio archive

DESCRIPTION
    The *header* structure, when the -c option of *cpio*(1) is not used, is:

        struct {
            short    h_magic,
                h_dev;
            ushort    h_ino,
                h_mode,
                h_uid,
                h_gid;
            short    h_nlink,
                h_rdev,
                h_mtime[2],
                h_namesize,
                h_filesize[2],
            char    h_name[h_namesize rounded to word];
        } Hdr;

    When the -c option is used, the *header* information is described by:

        sscanf(Chdr,"%6o%6o%6o%6o%6o%6o%6o%6o%11lo%6o%11lo%s",
            &Hdr.h_magic,&Hdr.h_dev,&Hdr.h_ino,&Hdr.h_mode,
            &Hdr.h_uid,&Hdr.h_gid,&Hdr.h_nlink,&Hdr.h_rdev,
            &Longtime,&Hdr.h_namesize,&Longfile,&Hdr.h_name);

    *Longtime* and *Longfile* are equivalent to *Hdr.h_mtime* and
    *Hdr.h_filesize*, respectively.  The contents of each file are
    recorded in an element of the array of varying length structures,
    *archive*, together with other items describeing the file.
    Every instance of *h_magic* contains the constant 070707
    (octal).  The items *h_dev* through *h_mtime* have meanings
    explained in *stat*(2).  The length of the null-terminated path
    name *h_name*, including the null byte, is given by
    *h_namesize*.

    The last record of the *archive* always contains the name TRAILER!!!.
    Special files, directories, and the trailer are recorded with
    *h_filesize* equal to zero.

SEE ALSO
    stat(2) in the *Programmer's Reference Manual*.
    cpio(1), find(1) in the *User's Reference Manual*.

Volume-Number: Volume 11, Number 14

From jsq  Mon May 11 01:08:22 1987
Posted-Date: 11 May 87 06:08:01 GMT
Received-Date: Mon, 11 May 87 01:08:22 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA03699; Mon, 11 May 87 01:08:22 CDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: tar or cpio?  N.064
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Date: 11 May 87 06:08:01 GMT
Apparently-To: std-unix-archive


N.064    April 23, 1987    ``Comments on 1003.1 N.048,'' Dominic Dunlop.

Comments on 1003.1 N48 (addition of cpio format to 1003.1 chapter 10)

1.
The structure proposed is archaic, in that it uses
    short    h_mtime[2]    and
    short    h_filesize[2]
yet says nothing about the ordering of the half-words
in the array.  This allows the possibility that different
implementations could make different "big endian" vs.
"little endian" decisions on the same underlying
architecture.

    Proposal: replace declarations above with
        long    h_mtime    and
        long    h_filesize
                or with
        time_t    h_mtime
        off_t    h_filesize

(Former probably more compatible with "shape" of
existing structgure; latter, using same types as
corresponding fields in struct stat, arguably
more correct (this argument could be extended
to other fields in struct Hdr as well)).

2.
Scanf format is incorrect.  It should be

        "%6ho%6ho%6ho%6ho%6ho%6ho%6ho%6ho%11lo%6ho%11lo%s"

(As I know to my cost, format published by AT&T
does not work on architectures where
        sizeof(int) == sizeof(long)
)

                Dominic Dunlop    4/23/87

Volume-Number: Volume 11, Number 15

From jsq  Mon May 11 07:08:09 1987
Posted-Date: 10 May 87 23:00:12 GMT
Received-Date: Mon, 11 May 87 07:08:09 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA08566; Mon, 11 May 87 07:08:09 CDT
From: Ralph Barker <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar or cpio?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 10 May 87 23:00:12 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Ralph Barker)

Relative to posting proposals already received and the proposal which you
will make to the working group:

I, for one, would be most interested in seeing the proposals you have
already received (assuming that the writers have included both their
suggestions and the underlying reasoning).

[ They're the articles just before yours.  -mod ]

I suspect that such interim postings might stir additional discussion, as
well.

As an aside, THANKS for your efforts within the working group.  The results
of your efforts (and the efforts of all members of the committees) are of
great importance to all of us in the UNIX community.

[ You're welcome. -mod ]

---
Ralph Barker, RALMAR Business Systems, 640 So Winchester Blvd, San Jose,CA 95128
uucp: ...{ucbvax,hplabs}!sun!idi---\!ralmar!ralph
      ...pyramid!amdahl!unixprt----/             Voice: [phone]




Volume-Number: Volume 11, Number 16

From jsq  Mon May 11 07:23:35 1987
Posted-Date: 11 May 87 09:22:07 GMT
Received-Date: Mon, 11 May 87 07:23:35 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA08756; Mon, 11 May 87 07:23:35 CDT
From: John Gilmore <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar or cpio?  Tar, of course.
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (John Gilmore)
Date: 11 May 87 09:22:07 GMT
Apparently-To: std-unix-archive

From: [e-mail] (John Gilmore)

I don't know anybody who's ever had trouble reading a tar tape
(assuming their hardware could read the medium).  I've heard of plenty
of troubles with cpio transfers, including the byte swap issues
mentioned so well by Guy, but also the fact that there are two formats
and one of them is inherently nonportable (and happens to be the
default) causes no end of confusion for users just trying to get their
data from here to there.  All versions of tar are compatible.
When researching tar for my implementation, I tracked down various
reports of tar tapes that could not be read by other tars, and all
turned out to be pilot error.  (Laura says she's heard of problems
when reading long-filename tapes on short-filename systems, but
cpio is no better at this, and I hear that V8 tar has been fixed to
rename long-name files while extracting them.)

Laura Creighton, sitting next to me, remembers that she had to rewrite
cpio several times when trying to read tapes sent from AT&T people
to her.  On utzoo, a V7 Unix system, there was no cpio, but she had
access to versions on other U of T machines.  She recalls things like
the PWB cpio writing tapes that could not be read by System III, and
System III writing tapes that could not be read by some releases of
System V, but without a lot of research she can't document these
claims.  (Anybody else out there run into this more recently?)

After looking at the cpio record format typed in by John, it looks like
it is a lot more Unix file system specific than tar, e.g. what are
inode numbers doing on a portable transfer format?  Also, the inode
numbers are defined to be unsigned shorts (or 6-digit octal) while in
many Unix systems, inode numbers are 32 bits long and will not fit in
this format.  Of course the binary format should not even be mentioned
in the standard, since an "unsigned short" has no portable
representation, but it's clear that the octal form is not big enough,
so what do we do?  Define a new standard "almost like current cpio" but
incompatible?  Let's stick with tar -- it doesn't expose the innards
of the V7 file system, and it works.

There is the additional advantage of a public domain implementation of
the proposed tar standard (written by me, available from mod.sources),
which also served to work out several bugs in the proposal.  This
implementation has been exchanging data with real source licensed Unix
tar's for years now without trouble.  It also implements some of the
things that cpio can do that Unix tar can't; in particular, reading the
list of files to be archived or extracted from standard input.


Volume-Number: Volume 11, Number 17

From jsq  Mon May 11 07:29:22 1987
Posted-Date: 11 May 87 12:29:11 GMT
Received-Date: Mon, 11 May 87 07:29:22 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA08815; Mon, 11 May 87 07:29:22 CDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: IEEE 1003.1 Rationale and Notes
Message-Id: <[e-mail]>
Date: 11 May 87 12:29:11 GMT
Apparently-To: std-unix-archive

Attached is a version of the first page of the draft IEEE 1003.1
Rationale and Notes Appendix.  I am posting as the editor of that
Rationale document, not as the moderator of comp.std.unix.

If you know of obscure sections of the Trial Use Standard that
need to be explained, or have other information related to the
Rationale document, please send it to me as soon as possible.

The next draft of the Rationale document will be distributed
on or about 1 June 1987, one week before the Phoenix USENIX
Conference, three weeks before the Seattle P1003.1 meeting.
I will have copies at USENIX and in Seattle.

It is not practical at this point for me to mail copies of the
previous draft.  However, if you are sufficiently interested,
send me your name and address and I will attempt to get you on the
list for the mailing of the next draft.

The next draft may be the last one directly funded by /usr/group,
and almost certainly will be the last to incorporate major changes
in topics or organization.  So it is advantageous to get your
comments in soon, although theoretically changes can be made up
until the draft Full Use Standard is ready for balloting.


             B.     Rationale and Notes

      This appendix summarizes the deliberations of the IEEE
      P1003.1 Working Group, the committee charged by IEEE with
      devising an interface standard for a portable operating
      system for computer environments, IEEE Std 1003.1, also
      known as POSIX.  This appendix is being developed under
      the sponsorship of /usr/group, the International Network
      of UNIX Systems Users, as part of an ongoing program of
      that association to support the IEEE 1003 Standards
      program efforts.  It is being published along with the
      standard to assist in the process of review.    It contains
      historical information concerning the contents of the
      standard and why features were included or discarded by the
      working group.  It also contains notes of interest to
      application programmers on recommended programming
      practices, emphasizing the consequences of some aspects of
      the standard that may not be immediately apparent.

      Material for this Rationale Document should be submitted
      directly to:

            John S. Quarterman
            Texas Internet Consulting
            Suite 500, Room 31
            Austin Centre
            701 Brazos
            Austin TX 78701-3243
            512-320-9031
            decvax!seismo!ut-sally!jsq

      by electronic mail and US mail.  If you have material that
      you think should be included in this document, please
      forward this immediately.  Your help in doing so will be
      greatly appreciated, and will contribute to the quality and
      acceptance of this standard.

        UNAPPROVED DRAFT.  All Rights Reserved by IEEE.
         Do not specify or claim conformance to this document.

Volume-Number: Volume 11, Number 18

From jsq  Mon May 11 14:55:17 1987
Posted-Date: 11 May 87 17:31:26 GMT
Received-Date: Mon, 11 May 87 14:55:17 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA16752; Mon, 11 May 87 14:55:17 CDT
From: Jim Cottrell <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar or cpio?  Tar, of course!
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 11 May 87 17:31:26 GMT
Apparently-To: std-unix-archive

To: gwyn@brl, hoptoad![e-mail]
Cc: [e-mail]
From: [e-mail] (Jim Cottrell)

? From: [e-mail] (John Gilmore)

? I don't know anybody who's ever had trouble reading a tar tape...
? All versions of tar are compatible.

Depends on what you mean. I have had troubles reading the original
TPC V6 & V7 distribution tapes under 4.2 BSD. Perhaps the format has
changed since then. Anyone have a tar that will read these tapes?

? There is the additional advantage of a public domain implementation of
? the proposed tar standard (written by me, available from mod.sources),

Kudos, John. I hope you also fixed special files as well. Ever try and
make a tar tape of the root? It barfs when it gets to /dev.

? From: Doug Gwyn <[e-mail]>

? In the real world one HAS to have a working "tar" if one exchanges files...

If I were paranoid I might think TPC was trying to limit this.

? I would prefer to remove tape archive format altogether from what is
? supposed to be a program/system interface specification (1003.1).  There
? simply isn't a single universal interchange medium anyway (not every
? system has 1/2" magtape, for example).

Tarchives are useful even they are never put on tape.

If it is still not clear, I favor tar as well. Perhaps the features
that motivated cpio's creation should be added to tar, as John has done.

I would also like to see an option not to cross mount points, that is
stay on the same partition. This should be added to several major utilities.

    (Root Boy) Jim "Just Say Yes" Cottrell    <[e-mail]>
    I hope I bought the right relish...  zzzzzzzzz...

Volume-Number: Volume 11, Number 19

From jsq  Tue May 12 13:20:44 1987
Posted-Date: 11 May 87 22:20:21 GMT
Received-Date: Tue, 12 May 87 13:20:44 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA06804; Tue, 12 May 87 13:20:44 CDT
From: Dennis Flaherty <[e-mail]>
Newsgroups: comp.std.unix
Subject: tar on RT11 v4
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 11 May 87 22:20:21 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Dennis Flaherty)

If tar works on every system, is there one for RT-11
version 4?  We have FORTRAN IV if that helps.  We have
run RT11 for years and are moving to Ultrix-11.  It
would be nice to be able to move the old archives.
Thanx in advance,
                                    Dennis Flaherty
marque![e-mail]   Marquette University
[e-mail]                      Milwaukee, WI
uwvax!marque!dennisf

[ I believe people were referring to every UNIX-related system.
We were discussing POSIX, the purpose of which is to codify
a version of the existing UNIX system interface.

One never knows, though:  someone might have a tar for RT11.
Or you could try adapting John Gilmore's public domain version,
if you have a C compiler. -mod ]

Volume-Number: Volume 11, Number 20

From jsq  Tue May 12 13:43:56 1987
Posted-Date: 10 May 87 14:19:17 GMT
Received-Date: Tue, 12 May 87 13:43:56 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA07261; Tue, 12 May 87 13:43:56 CDT
From: Chuck Forsberg <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar or cpio?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Organization: Omen Technology Inc, Portland Oregon
Date: 10 May 87 14:19:17 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Chuck Forsberg)

I have played with a program "afio" which is what cpio should/might have
been.  Main features are much faster than cpio, and reads all sorts of
cpio archives, most notably damaged archives.

Out of Sync --- It gets its own help!

This could be the basis of a POSIX cpio program.
Chuck Forsberg WA7KGX Author of Pro-YAM communications Tools for PCDOS and Unix
...!tektronix!reed!omen!caf  Omen Technology Inc "The High Reliability Software"
  17505-V Northwest Sauvie Island Road Portland OR 97231  Voice: 503-621-3406
TeleGodzilla BBS: 621-3746 2400/1200  CIS:70007,2304  Genie:CAF  Source:TCE022
  omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp
  omen!/usr/spool/uucppublic/FILES lists all uucp-able files, updated hourly

Volume-Number: Volume 11, Number 21

From jsq  Tue May 12 13:51:32 1987
Posted-Date: 12 May 87 13:14:24 GMT
Received-Date: Tue, 12 May 87 13:51:32 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA07492; Tue, 12 May 87 13:51:32 CDT
From: Joseph S. D. Yao <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar or cpio?
Summary: cpio pre-dates tar.  (not an argument for)
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Joseph S. D. Yao)
Organization: Hadron, Inc., Fairfax, VA
Date: 12 May 87 13:14:24 GMT
Apparently-To: std-unix-archive

In article <[e-mail]> [e-mail] (Guy Harris) writes:
>    3) It is less common.  Almost all UNIX systems that support
>       "cpio" also support "tar"; many UNIX systems that support
>       "tar" do not support "cpio".

Guy's arguments are mostly good, especially when reasoning about
the byte-order problem.  It should perhaps be noted, though, that
cpio pre-dates tar, and that there are probably numerous systems
"out there" that have cpio but not tar.  This, at least, seems to
be one of the arguments used by X/OPEN.

Of course, terms like "numerous", "almost all", and "many" are
hard to argue against, because they're so fuzzy.

Personally, I have found good use for both (cpio -p is rather
more elegant than the 2-tar equivalent kludge).  However, I have
had minutely more foul-ups with cpio than with tar.  (At least,
with current versions of tar.)

    Joe Yao        [e-mail] (not yet domainised)
    hadron!jsdy@{seismo.CSS.GOV,dtix.ARPA,decuac.DEC.COM}
{arinc,att,avatar,cos,decuac,dtix,ecogong,kcwc}!hadron!jsdy
     {netex,netxcom,rlgvax,seismo,smsdpg,sundc}!hadron!jsdy

Volume-Number: Volume 11, Number 22

From jsq  Tue May 12 13:58:01 1987
Posted-Date: 12 May 87 13:34:03 GMT
Received-Date: Tue, 12 May 87 13:58:01 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA07638; Tue, 12 May 87 13:58:01 CDT
From: Joseph S. D. Yao <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar or cpio?  Tar, of course!
Summary: Some help, I hope
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Joseph S. D. Yao)
Organization: Hadron, Inc., Fairfax, VA
Date: 12 May 87 13:34:03 GMT
Apparently-To: std-unix-archive

Reply-To: [e-mail] (Joseph S. D. Yao)

In article <[e-mail]> [e-mail] writes:
>Depends on what you mean. I have had troubles reading the original
>TPC V6 & V7 distribution tapes under 4.2 BSD. Perhaps the format has
>changed since then. Anyone have a tar that will read these tapes?

At this early hour, I can't think what "TPC" means.  When someone
tells me, I shall probably kick myself.  On the other hand, the
first UUG V6 & V7 distribution tapes were in tp or stp format.
(Remember those?)  When we first started switching to tar, we had
some problems with a tar for V6 and PWB System 1.X.  If I remember
correctly, the first few read OK and wrote trash.  They were based
on (the new) V7 tar.

Oh.  The Phone Company.  OK.  Cutesy I am  n o t  at this hour of
the morning.  (One dissenting vote heard from.)  My comment stands:
the V6 and PWB tapes, at least; and prob'ly V7 as well, were not
based on tar.

[ Readers are not required to read articles early in the morning just
because I often post them then.  :-)

The tar format in POSIX is derived from Version 7, as are most of the
tar programs in use today.  -mod ]

>I would also like to see an option not to cross mount points, that is
>stay on the same partition. This should be added to several major utilities.

Easy enough:
    [%$] su
    Password:
    # mount
    / on /dev/disk-0
    /prime on /dev/disk-1
    /prime/secundus on /dev/disk-2
    # unmount /dev/disk-2
    # cd /prime
    # tar xv

Other than that, this is awfully hard to do unless you are willing
to break modularity by sticking info about the FS into programs
which have no need to know about it whatsoever.

    Joe Yao        [e-mail] (not yet domainised)
    hadron!jsdy@{seismo.CSS.GOV,dtix.ARPA,decuac.DEC.COM}
{arinc,att,avatar,cos,decuac,dtix,ecogong,kcwc}!hadron!jsdy
     {netex,netxcom,rlgvax,seismo,smsdpg,sundc}!hadron!jsdy

Volume-Number: Volume 11, Number 23

From jsq  Wed May 13 12:36:41 1987
Posted-Date: 12 May 87 23:17:16 GMT
Received-Date: Wed, 13 May 87 12:36:41 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA29142; Wed, 13 May 87 12:36:41 CDT
From: Jim Cottrell <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar or cpio?  Tar, of course!
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 12 May 87 23:17:16 GMT
Apparently-To: std-unix-archive

In article <[e-mail]> [e-mail] writes:
>Depends on what you mean. I have had troubles reading the original
>TPC V6 & V7 distribution tapes under 4.2 BSD. Perhaps the format has
>changed since then. Anyone have a tar that will read these tapes?

Ok, the joke's on me. I'll try dump. Now on to Joe Yao's articles.

? >I would also like to see an option not to cross mount points, that is
? >stay on the same partition. This should be added to several major utilities.
?
? Easy enough:
?     [%$] su
?     Password:
?     # mount
?     / on /dev/disk-0
?     /prime on /dev/disk-1
?     /prime/secundus on /dev/disk-2
?     # unmount /dev/disk-2
?     # cd /prime
?     # tar xv
?
? Other than that, this is awfully hard to do unless you are willing
? to break modularity by sticking info about the FS into programs
? which have no need to know about it whatsoever.

Find on BSD4.3 has -xdev, and others have -prune. It is often desirable
to restrict searches to a single file system. Besides, to unmount /usr,
you have to kill all the daemons, and then the only editor you  have is ed.

? In article <[e-mail]> [e-mail] (Guy Harris) writes:
? >    3) It is less common.  Almost all UNIX systems that support
? >       "cpio" also support "tar"; many UNIX systems that support
? >       "tar" do not support "cpio".
?
? Guy's arguments are mostly good, especially when reasoning about
? the byte-order problem.  It should perhaps be noted, though, that
? cpio pre-dates tar, and that there are probably numerous systems
? "out there" that have cpio but not tar.  This, at least, seems to
? be one of the arguments used by X/OPEN.

Saying cpio predates tar might be strictly true, but tar hit the streets
first. Do you know of any UNII that have cpio but not tar?

?     Joe Yao        [e-mail] (not yet domainised)
?     hadron!jsdy@{seismo.CSS.GOV,dtix.ARPA,decuac.DEC.COM}
? {arinc,att,avatar,cos,decuac,dtix,ecogong,kcwc}!hadron!jsdy
?      {netex,netxcom,rlgvax,seismo,smsdpg,sundc}!hadron!jsdy

    (Root Boy) Jim "Just Say Yes" Cottrell    <[e-mail]>
    I just had my entire INTESTINAL TRACT coated with TEFLON!


Volume-Number: Volume 11, Number 24

From jsq  Wed May 13 12:41:37 1987
Posted-Date: 11 May 87 03:39:20 GMT
Received-Date: Wed, 13 May 87 12:41:37 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA29238; Wed, 13 May 87 12:41:37 CDT
From: Eric S. Raymond <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar and cpio
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 11 May 87 03:39:20 GMT
Apparently-To: std-unix-archive

I'd favor leaving in the tar specification *and* adding cpio. That way,
users of a POSIX-conforming system get the best of both. I think tar's
only real advantage is the multi-volume capability, otherwise cpio is much
superior. What would *really* win is a spec for multi-volume cpio (perhaps
P1003.2 should do this).

BTW, I contributed some stuff to one of the draft versions of Section 10
(specifically, the proposal for a multi-volume tar format with the
ability to recover from a missing volume that is also upward-compatible with
the present one), so I feel like I have something of a proprietary interest
in this stuff. Please email me with an update if you don't get enough response
to merit a posting.

---
      Eric S. Raymond
      UUCP:  {{seismo,ihnp4,rutgers}!cbmvax,sdcrdcf!burdvax}!snark!eric
      Post:  22 South Warren Avenue, Malvern, PA 19355
      Phone: [phone]

Volume-Number: Volume 11, Number 25

From jsq  Thu May 14 19:08:41 1987
Posted-Date: 13 May 87 14:48:51 GMT
Received-Date: Thu, 14 May 87 19:08:41 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA00631; Thu, 14 May 87 19:08:41 CDT
From: Joseph S. D. Yao <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar or cpio?  Tar, of course!
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Joseph S. D. Yao)
Date: 13 May 87 14:48:51 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Joseph S. D. Yao)

This is getting a bit far from UNIX/POSIX standards, but:

In letter <[e-mail]> [e-mail] (Root Boy Jim) writes:
>In article <[e-mail]> [e-mail] writes:
>>            ... I have had troubles reading the original
>>TPC V6 & V7 distribution tapes under 4.2 BSD.
>Ok, the joke's on me. I'll try dump. Now on to Joe Yao's articles.

Dump won't work either.  If I remember correctly, the first two blocks
(on V6) were boot blocks for two different tape drives, followed by
some stand-alone programs, and (perhaps in the next file) an IMAGE of
a V6 file system.  Then there were mixtures of disk images and tp tape
files.  V7 I'm not sure about; but as tar started (slightly buggy) in
V7, I vaguely recall that the distribution tapes were  n o t  in tar
format, either.  I may not be right about that last.

Note, BTW, that the V6 file system is not mountable on a V7 or later
system, including all current Berkeley and USG releases.

>? >I would also like to see an option not to cross mount points, that is
>? >stay on the same partition. This should be added to several major utilities.
>?        ... this is awfully hard to do unless you are willing
>? to break modularity by sticking info about the FS into programs
>? which have no need to know about it whatsoever.
>Find on BSD4.3 has -xdev, and others have -prune. It is often desirable
>to restrict searches to a single file system. Besides, to unmount /usr,
>you have to kill all the daemons, and then the only editor you  have is ed.

My statement stands.  Berkeley is  n o t  the best reference for proper
modularisation.  Find needs to know about a heckuva nawful lot, but it
would perhaps be desirable to have more general-purpose tools.

>? In article <[e-mail]> [e-mail] (Guy Harris) writes:
>? >              ...  Almost all UNIX systems that support
>? >       "cpio" also support "tar"; ...
>?            ..  It should perhaps be noted, though, that
>? cpio pre-dates tar, and that there are probably numerous systems
>? "out there" that have cpio but not tar.
>Saying cpio predates tar might be strictly true, but tar hit the streets
>first. Do you know of any UNII that have cpio but not tar?

I believe, Doctor McCoy, that that is what I just said.  Yes, cpio
hit the streets first, in PWB System 1.0, and in all of its descen-
dants, yeah down unto System III and System V Release 3.0 Version
1.1.  Those first few releases had no tar.  (I know, what held them
together then?)

And it's UNIXI, not UNII.  (Finally, something about standards, eh?)

From: hadron![e-mail] (Joseph S. D. Yao)
Subject: Re: tar or cpio?  Tar, of course!

Please amend prior letter.

It is neither UNIXI nor UNII, but Unices.

Thank you.    ;-)

    Joe Yao        [e-mail] (not yet domainised)
    hadron!jsdy@{seismo.CSS.GOV,dtix.ARPA,decuac.DEC.COM}
{arinc,att,avatar,cos,decuac,dtix,ecogong,kcwc}!hadron!jsdy
     {netex,netxcom,rlgvax,seismo,smsdpg,sundc}!hadron!jsdy

Volume-Number: Volume 11, Number 26

From jsq  Thu May 14 19:15:51 1987
Posted-Date: 13 May 87 01:04:28 GMT
Received-Date: Thu, 14 May 87 19:15:51 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA00810; Thu, 14 May 87 19:15:51 CDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: Re: tar or cpio?  Tar, of course.
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Reply-To: cwruecmp!nitrex![e-mail] (Rob Lake)
Organization: The Standard Oil Co., Cleveland
Date: 13 May 87 01:04:28 GMT
Apparently-To: std-unix-archive

From: decvax!cwruecmp!nitrex!rbl (Rob Lake)

In article <[e-mail]> [e-mail] (John Gilmore) writes:
>From: [e-mail] (John Gilmore)
>
>I don't know anybody who's ever had trouble reading a tar tape
>(assuming their hardware could read the medium).

I've had trouble reading tar tapes, given hardware that could read
the medium.  The problem was with block sizes that were too large
for the tape drive/controller/device driver to handle.  Never could
decide which it was, but --- having once designed a tape controller ---
pretty well assumed it was not the drive itself.

[ The 3B20 tape controller has this problem.  -mod ]

Rob Lake
decvax!cwruecmp!nitrex!rbl

Volume-Number: Volume 11, Number 27

From jsq  Thu May 14 19:23:04 1987
Posted-Date: 14 May 87 01:01:14 GMT
Received-Date: Thu, 14 May 87 19:23:04 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA00934; Thu, 14 May 87 19:23:04 CDT
From: Dave Brower <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar stop at mount points
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Dave Brower)
Organization: Relational Technology Inc, Alameda CA
Date: 14 May 87 01:01:14 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Dave Brower)

In article <[e-mail]> [e-mail] (Joseph S. D. Yao) writes:
>In article <[e-mail]> [e-mail] writes:
>>I would also like to see an option not to cross mount points, that is
>>stay on the same partition. This should be added to several major utilities.
>Other than that, this is awfully hard to do unless you are willing
>to break modularity by sticking info about the FS into programs
>which have no need to know about it whatsoever.

Hmmm.  Since stat(2) returns

          struct stat {
               dev_t  st_dev; /* device inode resides on */
               ino_t  st_ino; /* this inode's number */
        .
         };

it should be easy enough to see when you've crossed a device boundary,
and this seems portable under POSIX.  Why do you need additional info
about the FS?

-dB

Volume-Number: Volume 11, Number 28

From jsq  Fri May 15 12:28:34 1987
Posted-Date: 15 May 87 17:28:24 GMT
Received-Date: Fri, 15 May 87 12:28:34 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA13222; Fri, 15 May 87 12:28:34 CDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: Access to UNIX-Related Standards
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Moderator, John Quarterman)
Date: 15 May 87 17:28:24 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Moderator, John Quarterman)

This is the latest in a series of similar comp.std.unix articles.

Changes since the last posting include an updated P1003 meeting
schedule, an updated paper mail address for comp.std.unix moderator,
updated electronic address for Jim Isaak, updated P1003.2 description,
updated names, addresses and telephone numbers for the /usr/group
Working Groups, including the addition of information for the super
computing group, and a listing for the 4.3BSD manuals.

Corrections and additions to this article are solicited.


Access information is given in this article for the following standards:
IEEE 1003.1 (POSIX), 1003.2 (shell/tools), 1003.3 (verification)
/usr/group working groups on distributed file system, network interface,
    graphics/windows, database, internationalization,
    performance measurements, realtime, security, and super computing
X3H3.6 (display committee)
X3J11 (C language)
/usr/group Standard
System V Interface Definition (SVID, or The Purple Book)
X/OPEN PORTABILITY GUIDE (The Green Book)
4.3BSD Manuals


UNIX is a Registered Trademark of AT&T.
POSIX and IEEE are trademarks of the Institute of Electrical
    and Electronic Engineers, Inc.
X/OPEN is a licensed trademark of the X/OPEN Group Members.


The IEEE P1003 Portable Operating System for Computer Environments Committee
is sometimes known colloquially as the UNIX Standards Committee.
They published the 1003.1 "POSIX" Trial Use Standard in April 1986.
According to its Foreword:

    The purpose of this document is to define a standard
    operating system interface and environment based on the
    UNIX Operating System documentation to support application
    portability at the source level.  This is intended for
    systems implementors and applications software developers.

Published copies are available at $19.95,
with bulk purchasing discounts available.
Call the IEEE Computer Society in Los Angeles

        714-821-8380

and ask for Book #967.  Or contact:

        IEEE Service Center
        445 Hoes Ln.
        Piscataway, NJ 08854

and ask for "IEEE 1003.1 Trial Use Standard" - stock number SH10546.

The Trial Use Standard will be available for comments for a period
such as a year.  The current target for a Full Use Standard is Fall 1987.
IEEE has initiated the process to have the 1003.1 effort brought into
the International Organization for Standardization (ISO) arena.

Machine readable copies of the Trial Use Standard are not and will
not be available.

There is a paper mailing list by which interested parties may get
copies of drafts of the standard.  To get on it, or to submit comments
directly to the committee, mail to:

        James Isaak
        Chairperson, IEEE/CS P1003
        Digital Equipment    MK02-2/B05
        Continental Blvd.
        Merrimack, NH      03054-0403
        decvax!isaak
        603-884-1913

Sufficiently interested parties may join the working group.

Related working groups are
    group    subject        co-chairs
    1003.2    shell and tools    Hal Jespersen (UniSoft), Don Cragun (Sun)
    1003.3    verification    Roger Martin (NBS), Carol Raye (AT&T)

Inquiries regarding 1003.2 and 1003.3 should go to the same address
as for 1003.1.


The next scheduled meetings of the P1003 working groups are,
in 1987 and 1988:

June    22-26  P1003.[13]  Seattle (changed from USENIX week in Phoenix to
        give us better working attendance)    Host:  CDC
        P1003.2 will not meet in Seattle, due to scheduling
        problems related to the extreme member overlap between
        1003.1 and 1003.2 and the need for 1003.1 to meet all week
        in order to speed finishing the Full Use Standard.
        But there will be a 1003.2 BOF Tuesday, 6/23, 19:00-22:00,
        to exchange information and assess the status of the command
        descriptions distributed in the April meeting.

Sept.    14-18    Framingham, Massachusetts (same time and place as X3J11)
(Sept 7th is Labor day, and that week is ISO TC97 SC22 meeting in Wash DC)

Dec.    7-11    San Diego

April 1988    Japan, depending on potential attendance.

There is also a balloting group (which intersects with the working group).
This is more difficult.  Contact Jim Isaak for details.  I will repost
them in this newsgroup if there is sufficient interest.

Here are some details from Hal Jespersen regarding P1003.2:

The IEEE P1003.2 "Shell and Utilities" Working Group is developing a
proposed standard to complement the 1003.1 POSIX standard.  It will
consist of

    a shell command language (currently planned to be based on the
    Bourne Shell),

    groups of utility programs, or commands,

    programmatic interfaces to the shell (system(), popen()) and
    related facilities (regular expressions, file name expansion,
    etc.)

    defined environments (variables, file hierarchies, etc) that
    applications may rely upon

    tools for installing application programs onto conforming
    systems

which will allow application programs to be developed out of existing
pieces, in the UNIX tradition.  The scope of the standard emphasizes
commands and features that are more typically used by shell scripts or
C language programs than those that are oriented to the terminal user
with windows, mice, visual shells, and so forth.

There has been some controversy in the Working Group about
clarifying the scope of the 1003.2 standard in regard to its
relationship with 1003.1.  The Working Group is attempting to
produce a standard that will assume the structure and
philosophy of a POSIX system is available, but it will not
require a fully conforming implementation as a base.  For
example, it should be feasible to eventually produce a 1003.2
interface on a V7 system, or on a system very close to POSIX,
but missing a few crucial features (as long as the shell and
utilities didn't need them).  However, the proposed standard
will *not* be unnecessarily watered down simply to allow
non-POSIX systems to conform.

The group is currently seeking proposals for groupings of commands that
may be offered by implementors.  As groups are identified, command
descriptions will be solicited.  There is no requirement that the commands
be in System V or BSD today, but they should realistically be commands
that are commonly found in most existing implementations.


There are three Institutional Representatives to P1003:  John Quarterman
from USENIX, Heinz Lycklama from /usr/group, and Martha Nalebuf from X/OPEN.

As the one from USENIX, one of my functions is to get comments from the
USENIX membership and the general public to the committee.  One of the
ways I try to do that is by moderating this newsgroup, comp.std.unix
(formerly known as mod.std.unix).  An article related to this one
appeared in the September/October 1986 ;login: (The USENIX Association
Newsletter).  I'm also currently on the USENIX Board of Directors.
Comments, suggestions, etc., may be sent to

        John S. Quarterman
        Texas Internet Consulting
        Suite 500, Room 31
        Austin Centre
        701 Brazos
        Austin TX 78701-3243
        512-320-9031
        usenix!jsq

For comp.std.unix:
Comments:    ut-sally!std-unix-request [e-mail]
Submissions:    ut-sally!std-unix        [e-mail]

The May/June 1987 issue of CommUNIXations (the /usr/group newsletter)
contains a report by Heinz Lycklama on the /usr/group Technical Committee
working groups which met in January 1987.

If you are interested in starting another working group, contact
Heinz Lycklama:

        Heinz Lycklama
        Interactive Systems Corp.
        2401 Colorado Ave., 3rd Floor
        Santa Monica, CA 90404
        [phone]
        decvax!cca!ima!heinz


Here is contact information for /usr/group working groups as taken from
the CommUNIXations article mentioned above, and updated by later information
from Heinz Lycklama.

/usr/group Working Group on Distributed File System:
    Laurence Brown            Frederick Glover
    AT&T Information Systems    MK02-1/H10
    190 River Road            Digital Equipment Corporation
    Summit, NJ  07933        Continental Boulevard
    201-522-6046            Merrimack, NH  03054-0430
    attunix!bump            603-884-5111
                    decvax!fglover

/usr/group Working Group on Network Interface:
    Steve Albert
    AT&T Information Systems
    190 River Road, Rm. A-114
    Summit, NJ  07901
    [phone]
    attunix!ssa

/usr/group Working Group on Internationalization:
    Karen Barnes
    Hewlett-Packard Co.
    19447 Pruneridge Ave.
    M/S 47U2
    Cupertino, CA 95014
    [phone]

/usr/group Working Group on Graphics/Windows:
    Tom Greene
    Apollo Computer, Inc.
    330 Billerica Road
    Chelmsford, MA  01824
    [phone], ext. 7581

/usr/group Working Group on Realtime:
    Bill Corwin
    Intel Corp.
    5200 Elam Young Pkwy
    Hillsboro, OR 97123
    [phone]

/usr/group Working Group on Database:
    Val Skalabrin
    Unify Corp.
    1111 Howe Ave.
    Sacramento, CA 95825
    [phone]

/usr/group Working Group on Performance Measurements:
    Ram Chelluri            Dave Hinnant
    AT&T Computer Systems        SCI Systems, Inc.
    Room E15B            Ste 325, Pamlico Bldg
    4513 Western Ave.        Research Triangle Pk, NC 27709
    Lisle, IL 60532            [phone]
    [phone]

/usr/group Working Group on Security:
    Steve Sutton            Ms. Jeanne Baccash
    Consultant, Addamax        AT&T UNIX Systems Engineering
    1107 S. Orchard            190 River Road
    Urbana, IL  61801        Summit, NJ  07901
    217-344-0996            201-522-6028
                    attunix!jeanne

/usr/group Working Group on Super Computing:
    Karen Sheaffer            Robin O'Neill
    Sandia National Laboratory    Lawrence Livermore Laboratory
    P.O. Box 969            P.O. Box 5509, L560
    Livermore, CA  94550        Livermore, CA  94550
    415-422-3431            415-422-0973
                    oneill#[e-mail] Co-chair


The X3H3.6 display management committee has recently formed to develop
a model to support current and future window management systems, yet
is not based directly on any existing system.  The chair solicits
help and participation:

        Georges Grinstein
        wanginst!ulowell!grinstein


The Abstract of the 1003.1 Trial Use Standard adds:

    This interface is a complement to the C Programming Language
    in the C Information Bulletin prepared by Technical Committee X3J11
    of the Accredited Standards Committee X3, Information Processing
    Systems, further specifying an environment for portable application
    software.

X3J11 is sometimes known as the C Standards Committee.  Their liaison to
P1003 is

        Don Kretsch
        AT&T
        190 River Road
        Summit, NJ 07901

A contact for information regarding publications and working groups is

        Thomas Plum
        Vice Chair, X3J11 Committee
        Plum Hall Inc.
        1 Spruce Avenue
        Cardiff, New Jersey 08232

The current document may be ordered from

        Global Press
        2625 Hickory St.
        P.O. Box 2504
        Santa Anna, CA 92707-3783
        U.S.A.
        800-854-7179
        [phone] (from outside the U.S., ask for extension 245.)
        TELEX 692 373

Ask for the X3.159 draft standard.  The price is $65.


The /usr/group Standard is a principal ancestor of P1003.1, X/OPEN,
and X3J11.  It may be ordered for $15.00 from:

        /usr/group Standards Committee
        4655 Old Ironsides Drive, Suite 200
        Santa Clara, California 95054
        [phone]


The System V Interface Definition (The Purple Book, or SVID).
This is the AT&T standard and is one of the most frequently-used
references of the IEEE 1003 committee.

        AT&T Customer Information Center
        Attn:  Customer Service Representative
        P.O. Box 19901
        Indianapolis, IN 46219
        U.S.A.

        800-432-6600 (Inside U.S.A.)
        800-255-1242 (Inside Canada)
        317-352-8557 (Outside U.S.A. and Canada)

    System V Interface Definition, Issue 2
    should be ordered by the following select codes:

    Select Code:    Volume:        Topics:
    320-011        Volume I    Base System
                    Kernel Extension
    320-012        Volume II    Basic Utilities Extension
                    Advanced Utilities Extension
                    Software Development Extension
                    Administered System Extension
                    Terminal Volume Interface Extension
    320-013        Volume III    Base System Addendum
                    Terminal Interface Extension
                    Network Services Extension
    307-131        I, II, III    (all three volumes)

The price is about 37 U.S. dollars for each volume or $84 for all three.
Major credit cards are accepted for telephone orders:  mail orders
should include a check or money order, payable to AT&T.


The X/OPEN PORTABILITY GUIDE (The Green Book)
is another reference frequently used by IEEE 1003.

The X/OPEN Group is "Ten of the world's major information system
suppliers" (currently Bull, DEC, Ericsson, Hewlett-Packard, ICL,
NIXDORF, Olivetti, Philips, Siemens, Unisys, and AT&T) who have
produced a document intended to promote the writing of portable
facilities.  They closely follow both SVID and POSIX, and cite
the /usr/group standard as contributing, but X/OPEN's books
cover a wider area than any of those.

The book is published by

        Elsevier Science Publishers B.V.
        Book Order Department
        P.O. Box 1991
        1000 BZ Amsterdam
        The Netherlands

and distributed in the U.S.A. and Canada by:

        Elsevier Science Publishing Company, Inc.
        52 Vanderbilt Avenue
        New York, NY 10017
        U.S.A.

There are currently five volumes:
    1) System V Specification Commands and Utilities
    2) System V Specification System Calls and Libraries
    3) System V Specification Supplementary Definitions
    4) Programming Languages
    5) Data Management

They take a large number of credit cards and other forms of payment.


Finally, 4.2BSD and 4.3BSD have influenced POSIX in a number of areas.
The best reference on them is the 4.3BSD manuals, published by USENIX.
An order form may be obtained from:

        Howard Press
        c/o USENIX Association
        P.O. Box 2299
        Berkeley, CA 94710

        415-528-8649
        {ucbvax,decvax}!usenix!office

4.3BSD User's Manual Set (3 volumes)        $25.00
    User's Reference Manual
    User's Supplementary Documents
    Master Index

4.3BSD Programmer's Manual Set (3 volumes)    $25.00
    Programmer's Reference Maual
    Programmer's Supplementary Documents, Volume 1
    Programmer's Supplementary Documents, Volume 2

4.3BSD System Manager's Manual (1 volume)    $10.00

Unfortunately, to order you must represent a USENIX Association
Institutional or Supporting Member, because the manuals can only
be sold to licensees of 4.3BSD and one of 32V, System III, or System V,
and those membership categories are USENIX's mechanism of checking licenses.

Volume-Number: Volume 11, Number 29

From jsq  Fri May 15 13:49:59 1987
Posted-Date: 15 May 87 18:42:11 GMT
Received-Date: Fri, 15 May 87 13:49:59 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA14279; Fri, 15 May 87 13:49:59 CDT
From: Dan Franklin <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re:  Access to UNIX-Related Standards
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 15 May 87 18:42:11 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Dan Franklin)

> The IEEE P1003 Portable Operating System for Computer Environments ...
> ...
> Published copies are available at $19.95,
> with bulk purchasing discounts available.
> Call the IEEE Computer Society in Los Angeles
>   714-821-8380
> and ask for Book #967...

This doesn't work.  I just called that number, and was told they
only do phone ordering for books costing $25 or more (and they
confirmed the price of $19.95).  Instead, they told me to mail my
order to

    IEEE Computer Society
    P.O. Box 80452
    Worldway Postal Center
    Los Angeles, Ca. 90080

including a check for $19.95 + $4 for shipping and handling, plus
$2 if I wanted it shipped UPS instead of whatever snail mail they
would normally use (I don't remember what she said it was, probably
4th class).  I will now try that.

Too bad they don't charge $5.05 more for it.

    Dan Franklin

Volume-Number: Volume 11, Number 30

From jsq  Fri May 15 19:21:45 1987
Posted-Date: 15 May 87 20:24:03 GMT
Received-Date: Fri, 15 May 87 19:21:45 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA19471; Fri, 15 May 87 19:21:45 CDT
From: Rick Adams <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Access to UNIX-Related Standards
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Rick Adams)
Date: 15 May 87 20:24:03 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Rick Adams)

Are the dbm libraries included in POSIX? If not, they certainly should be.
SVID doesn't provide any similar capability that I know of.

---rick

[ That's outside the scope of POSIX, i.e., P1003.1.  It might fit in
what P1003.2 is doing.  -mod ]

Volume-Number: Volume 11, Number 31

From jsq  Mon May 18 20:48:20 1987
Posted-Date: 17 May 87 19:15:20 GMT
Received-Date: Mon, 18 May 87 20:48:20 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA09898; Mon, 18 May 87 20:48:20 CDT
From: Joseph S. D. Yao <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar stop at mount points
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Joseph S. D. Yao)
Organization: Hadron, Inc., Fairfax, VA
Date: 17 May 87 19:15:20 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Joseph S. D. Yao)

In article <[e-mail]> you write:
>From: [e-mail] (Dave Brower)
>
>In article <[e-mail]> [e-mail] (Joseph S. D. Yao) writes:
>>In article <[e-mail]> [e-mail] writes:
>>>I would also like to see an option not to cross mount points ...
>>        .. this is awfully hard to do unless you are willing
>>to break modularity by sticking info about the FS into programs
>>which have no need to know about it whatsoever.
>Hmmm.  Since stat(2) returns
>               dev_t  st_dev; /* device inode resides on */
>it should be easy enough to see when you've crossed a device boundary,

Jim (rbj) has mentioned this, and this is of course correct.  I'd
been thinking of a much more elaborate schema.  This is still in fact
new information that 'find' hadn't needed before; but since 'find'
already has to be somewhat sophisticated about the file system,
this isn't such a bad breach of modularity as I'd imagined.  Now,
however, think what you'd have to do (e.g.) to add an option to
'cp' not to copy across device boundaries ...  (rbj had wanted this
capability widely transplanted.)

What I'd been thinking of was something on the order of:
    find / \( -fs /usr -o -fsd /dev/rdsk/ra11 \) -a -print
which is truly terrible to implement.  (Don't anyone flame me
for using archaic "-a"s: current 'find' accepts them, and old
'find' requires them.)
--

    Joe Yao        [e-mail] (not yet domainised)
    hadron!jsdy@{seismo.CSS.GOV,dtix.ARPA,decuac.DEC.COM}
{arinc,att,avatar,cos,decuac,dtix,ecogong,kcwc}!hadron!jsdy
     {netex,netxcom,rlgvax,seismo,smsdpg,sundc}!hadron!jsdy

Volume-Number: Volume 11, Number 32

From jsq  Sun May 24 12:23:08 1987
Posted-Date: 24 May 87 17:22:58 GMT
Received-Date: Sun, 24 May 87 12:23:08 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA27099; Sun, 24 May 87 12:23:08 CDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: Access to UNIX User Groups and Publications
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 24 May 87 17:22:58 GMT
Apparently-To: std-unix-archive

This is the latest in a series of similar comp.std.unix articles.
The convention schedules and writeups for USENIX and /usr/group have
been updated with information from their respective Executive Directors,
and the next conferences of AUUG and EUUG are indicated.

Corrections and additions to this article are solicited.


Access information is given in this article for the following:
user groups:    USENIX, /usr/group, EUUG, AUUG, DECUS
newsletters:    ;login:, CommUNIXations, EUUG, AUUGN
magazines:    UNIX REVIEW, UNIX/WORLD

UNIX is a Registered Trademark of AT&T.


USENIX is "The Professional and Technical UNIX(R) Association."

        USENIX Association
        P.O. Box 2299
        Berkeley, CA 94710
        415-528-8649
        {ucbvax,decvax}!usenix!office

USENIX sponsors two USENIX Conferences a year, featuring technical papers,
as well as tutorials, and with vendor exhibits at the summer conferences:

    Jun  8-12 1987    Hyatt Regency, Phoenix, AZ
    Feb 10-12 1988    Registry Hotel, Dallas, TX, concurrent with Uniforum
    Jun 21-24 1988    Hilton Hotel, San Francisco, CA
    Feb  1- 3 1989    Town and Country Hotel, San Diego, CA
    Jun 13-16 1989    Hyatt Regency, Baltimore, MD
    Jun 11-15 1990    Marriott Hotel, Anaheim, CA

They also sponsor workshops, such as
    Apr  9-10 1987    Palace Hotel, Philadelphia, PA
        Large Installation System Administrator's Workshop
    Oct  8- 9 1987    Cambridge Marriott, Cambridge, MA
        4th USENIX Computer Graphics Workshop
    Oct      1987        Contact Jim McGinness: decvax!jmcg
        POSIX Implementation Workshop
    Nov      1987    Santa Fe, NM    Contact Dave Yost:
        C++ Workshop    {attmail,uunet,usenix}!grand!day

Proceedings for all conferences and workshops are available at
the door and by mail later.

USENIX publishes ";login:  The USENIX Association Newsletter"
bimonthly.  It is sent free of charge to all their members and
includes technical papers.  There is a USENET newsgroup,
comp.org.usenix, for discussion of USENIX-related matters.

They also publish an edition of the 4.3BSD manuals, and they
occasionally sponsor experiments, such as methods of improving
the USENET and UUCP networks, that are of interest and use to
the membership.  They distribute tapes of contributed software
and are pursuing expanding that activity.

There is a USENIX Institutional Representative on the IEEE P1003
Portable Operating System for Computer Environments Committee.
That representative also moderates the USENET newsgroup comp.std.unix,
which is for discussion of UNIX-related standards, especially P1003.
For more details, see the posting in comp.std.unix about Access
to UNIX-Related Standards.


/usr/group is a non-profit trade association dedicated to the promotion
of products and services based on the UNIX operating system.

        /usr/group
        4655 Old Ironsides Drive, Suite 200
        Santa Clara, California 95054
        tel: [phone]
        fax: [phone]

The annual UniForum Conference and Trade Show is sponsored by /usr/group
and features vendor exhibits, as well as tutorials and technical sessions.

    Feb 8-11 1988    Infomart, Dallas, TX, concurrent with USENIX
    Feb 28-Mar 3 1989 Moscone Center, San Francisco, CA
    Jan 23-26 1990    Washington Hilton, Washington, DC
    Jan 22-25 1991    Infomart, Dallas, TX
    Jan 21-24 1992    Moscone Center, San Francisco CA (tentative)

They also sponsor a regional show, UniForum D.C.:

    Aug 2-4 1988    Washington Hilton Hotel, Washington, D.C.
    Aug 1-3 1989    Washington Hilton Hotel, Washington, D.C.

Proceedings for all conferences are available at the shows and later
by mail.

/usr/group publishes "CommUNIXations", a member magazine that featues
articles by industry leaders and observers, technical issues,
standards coverage, and new product announcements.

/usr/group also publishes the "UNIX Products Directory," which lists
products and services developed specifically for the UNIX operating system.
"/usr/digest" is also published by /usr/group.  This newsletter covers
product announcements and industry projections, and is sent to members
biweekly.

/usr/group has long been deeply involved in UNIX standardization,
having sponsored the "/usr/group 1984 Standard", providing an Institutional
Representative to the IEEE P1003 Portable Operating System for Computer
Environments Committee, and sponsoring the /usr/group Working Groups
on areas that P1003 has not yet addressed.  They have recently produced
an Executive Summary of the POSIX standard and funded production of a
draft of a Rationale and Notes appendix for that standard.


EUUG is the European UNIX systems Users Group.

        EUUG secretariat
        Owles Hall
        Buntingford
        Herts SG9 9PL
        England
        seismo!mcvax!euug

They have a newsletter and hold two conferences a year.
The next one is in Dublin, Ireland, in September.


AUUG is the Australian UNIX systems Users Group.

        AUUG
        P.O. Box 366
        Kensington
        N.S.W.    2033
        Australia

        seismo!munnari!auug
        [e-mail]

Phone contact can occasionally be made at [phone]

AUUG holds biennial conferences, usually of 2 days each.
They publish a newsletter (AUUGN) at a frequency defined
to be every 2 months.

The next meeting is in Sydney, 27-28 August 1987.
The host is by NSWIT, and for more info people should contact
[e-mail], or to submit a paper, [e-mail]
(deadline for Abstracts is July 10).


There are similar groups in other parts of the world, such as Japan and
Korea.  If such a group wishes to be included in later versions of this
access list, they should please send me information.


Also, DECUS, the Digital Equipment Computer Users Society,
has a UNIX SIG (Special Interest Group) which participates
in its meetings, which are held twice a year.

        DECUS U.S. Chapter
        219 Boston Post Road, BP02
        Marlboro, Massachusetts  01752-1850
        617-480-3418

See also the USENET newsgroup comp.org.decus.


The two main general circulation magazines about the UNIX system are

    UNIX REVIEW            UNIX/WORLD
    Miller Freeman Publications Co.    Tech Valley Publishing
    500 Howard Street        444 Castro St.
    San Francisco, CA 94105        Mountain View, CA 94041
    415-397-1881            415-940-1500


Volume-Number: Volume 10, Number 20





Volume-Number: Volume 11, Number 33

From jsq  Sun May 24 12:36:23 1987
Posted-Date: 20 May 87 20:37:12 GMT
Received-Date: Sun, 24 May 87 12:36:23 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA27234; Sun, 24 May 87 12:36:23 CDT
From: Andrew Tannenbaum <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar or cpio?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Andrew Tannenbaum)
Organization: Interactive Systems, Boston, MA
Date: 20 May 87 20:37:12 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Andrew Tannenbaum)

I don't have Section 10 of the POSIX Trial Use Standard, but I am
interested in what happens to tar and cpio in POSIX.

I see that the netnews discussion of this has been partly a
popularity contest between tar and cpio.  There are more
important issues to discuss than people's provincial biases.  If
you come from BSD land, you probably like tar.  If you come from
AT&T land, you probably like cpio.

I have some comments about cpio, since it is my personal favorite.
They apply to both the file format and to the program function.
Some comments apply to tar as well.

I like the idea of cpio taking a list of files on stdin.  I wish
tar had this option.  tar cv `find / -print | fgrep -v -f except.file`
doesn't cut it.

[ Evidently John Gilmore's public domain implementation that he
posted to comp.sources has this.  I know of no proprietary version
that does.  -mod ]

cpio's binary format should have been killed off long ago.
cpio has a 'portable' format, which still has several problems:

-       Byte swapping and its friends.
    There are systems which swap bytes and/or halfwords.  There are
    even systems which xor 0 and 1 bits on tapes.  If CPIO
    wrote a magic number 0x12345678 in the header, it could resolve
    these problems painlessly.

-       I agree that the binary cpio header is silly.
    The portable header is all printable ASCII data, but the
    filename is terminated by a null, which makes it harder to play
    with the archive.  Here is a shar-like program which makes a
    cpio archive which can unpack itself.

<<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>>
#! /bin/sh
# take a list of files on stdin and make them into a bundle which
# can be passed through sh to extract them.
cat << \!
#!/bin/sh
# cpio archive
(read a; read a; read a; read a; cat) < $0 | cpio -icdm
exit
!
cpio -oac
<<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>><<>>

    As I recall, it can have problems because of the fact that the
    filename is null-terminated, like if you try to read its
    output into a mail message with an editor.  It would also be
    neighborly if the ASCII header was more human readable, a space
    or carriage return here or there wouldn't hurt at all.

    I realize that this is a standardization effort, but if you are
    going to enhance the format for some portability reason, you
    might want to consider my enhancement suggestions.

-       The familiar problems with damaged archives should be
    fixed (Out of phase--get help).

-    There are systems which need to extend the archive
    formats in local ways, for instance, to add extra mode
    information for a secure UNIX implementation, or file type
    information when the UNIX system deals with other types of file
    systems.  It would be very useful to have a compatible way to
    extend the header such that any system could check the local
    field and either use or ignore the information.  Right
    now, there is little hope for compatibility, the only
    solutions I can think of (various kinds of shadow files
    which contain mode info) are quite kludgy.

-       These programs should deal with multiple tape archives
    in a standard way.  I have seen many local hacks to do
    this.

-       Blocksizes for speed, space, and streaming efficiency are best
    handled by blocking filters rather than by hacks like -B.  I
    have heard of ctccpio, but can only worry about what it
    actually is.  How many programs are going to have to have
    knowledge about how many goofy devices?  I don't understand why
    cpio has to know anything about a device.  This is UNIX, isn't
    it?  Which brings us back to the question of multi-tape
    archives, maybe the blocking filter should also handle the
    multi-tape problem?  This means lots of data travels over a
    pipe.  Modern OS's should be able to do something smart here.
    (The multi-tape question leaves me with a queasy feeling.)

I would like to see a discussion about tar and cpio rather than
opinions about which is better.  I am particularly concerned about
extending the header format to deal with atypical file types.

    Andrew Tannenbaum   Interactive   Boston, MA   [phone]

Volume-Number: Volume 11, Number 34

From jsq  Sun May 24 12:56:33 1987
Posted-Date: 21 May 87 13:22:52 GMT
Received-Date: Sun, 24 May 87 12:56:33 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA27637; Sun, 24 May 87 12:56:33 CDT
From: Mike Akre <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar stop at mount points
Summary: find knows how to do this in SVR3
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: rutgers.edu!moss!cuuxb![e-mail] (Mike Akre)
Organization: AT&T, Data Systems Division, Lisle, IL
Date: 21 May 87 13:22:52 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Mike Akre)

In article <[e-mail]> [e-mail] (Joseph S. D. Yao) writes:
>>Hmmm.  Since stat(2) returns
>>               dev_t  st_dev; /* device inode resides on */
>>it should be easy enough to see when you've crossed a device boundary,
>
>What I'd been thinking of was something on the order of:
>    find / \( -fs /usr -o -fsd /dev/rdsk/ra11 \) -a -print

find knows how to not cross mount points in System V Release 3.0 and later.
It has a new option "-mount" that will restrict find's searching to the
filesystem containing the directory specified.

I do full backups of the root filesystem with something like this:

    cd /
    find . -mount -depth -print | cpio -oacB >/dev/rmt/0m

Mike Akre
Lisle, IL

Volume-Number: Volume 11, Number 35

From jsq  Tue May 26 21:10:45 1987
Posted-Date: 26 May 87 23:54:40 GMT
Received-Date: Tue, 26 May 87 21:10:45 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA18983; Tue, 26 May 87 21:10:45 CDT
From: John Gilmore <[e-mail]>
Newsgroups: comp.std.unix
Subject: More tar/cpio
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (John Gilmore)
Date: 26 May 87 23:54:40 GMT
Apparently-To: std-unix-archive

From: [e-mail] (John Gilmore)

In article <[e-mail]>, [e-mail] (Mike Akre) writes:
> Find knows how to not cross mount points in System V Release 3.0 and later.
> It has a new option "-mount" that will restrict find's searching to the
> filesystem containing the directory specified.

SunOS 3.2 has a similar option, called "-xdev"; it says not to cross into
a different device than the one on which the filename argument resides.
As far as I can see, the two are the same.

Ted Nolan ([e-mail]) posted diffs to Unix tar to add a "T"
option to read filenames from standard input.  However, his changes
only worked for creating archives, not for reading from them.  His
changes were in net.sources posted 17 July 1984, as an "ed" script
for editing 4.2BSD tar.c.  I can provide copies if anybody wants 'em.
I also generated a context diff from this and can provide that.

It is true that my PD tar can read a list of filenames from standard
input, for both creating and reading archives.  It can also deal with a
large list of names to extract even on a small memory system, by giving
it another option letter indicating that the list on stdin is sorted to
match the tape.

I think that the argument boils down to:

*    Neither tar nor cpio is perfect for what we want.

*    People like cpio's user interface better.

*    Tar's format on the tape is more portable.

As a standards effort, we can't just create a new "portable" format
which is not portable to all the old Unix systems.  If we claim the
standard format is "cpio" or "tar" format, the old cpio or tar should
be able to read it.  All the suggestions for improving cpio format (Andy
Tannenbaum's are a good example) ignore interchange with older systems.
If we decide on a format which neither tar nor cpio, as they now stand,
can read, let's invent a new name for the format and the command (posio,
for portable standard I/O?  That sounds too much like stdio though.
Posar?).

Personally I think what matters most is the interchange format, not the
user interface; this is why I favor tar.  The user or system implementer
can always provide a better, or additional, user interface but they
are stuck with the interchange format.

As I recall, the draft I saw standardized the interchange format but
specifically did not standardize the command used to generate that
format.  How would people feel about a compromise wherein a new option
added to "cpio" would cause it to generate or read POSIX interchange tapes,
which might happen to have a format compatible with V7 tar?  Vendors
could make this option the default if desired, requiring the user to
specify an option to write binary or ascii cpio tapes.  When reading,
it could figure out the format of a tape without user intervention.

Volume-Number: Volume 11, Number 36

From jsq  Sat May 30 21:27:04 1987
Posted-Date: 28 May 87 22:49:57 GMT
Received-Date: Sat, 30 May 87 21:27:04 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA11616; Sat, 30 May 87 21:27:04 CDT
From: Paul Eggert <[e-mail]>
Newsgroups: comp.std.unix
Subject: cpio inode number limit is too low
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: sdcrdcf![e-mail] (Paul Eggert)
Organization: Unisys Santa Monica
Date: 28 May 87 22:49:57 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Paul Eggert)

I spent a day last week on cpio software installation problems, and would like
to amplify a point John Gilmore made in <[e-mail]>: the cpio -c
format does not represent enough inode numbers.  It represents only inode
numbers less than 2^18 = 262144.  Even our venerable Fujitsu Eagle has a
filesystem with 108544 inodes; some filesystems today, and many more soon, will
exceed this limit.

Most implementations of cpio wrongly examine just the bottom 16 bits of the
inode number, even when the -c flag is used, because in the source code a
crucial variable is declared "unsigned short".  Some implementations (e.g. Sun
UNIX 3.2; Sun has promised a fix) due to other coding errors sometimes look
only at the bottom 15 bits.  Hence if you want to create a portable cpio tape
today, you must not trust your destination cpio to properly restore two files
whose inode numbers are equal modulo 2^15: the destination cpio might
mistakenly think the second file is a hard link to the first.  The problem can
occur even if no two source files are hard links, or even if you are using cpio
-p where no tape is involved.  My best workaround for this problem would be
laborious:  make the tape after reconfiguring the source filesystem to have no
more than 2^15 = 32768 inodes.  It was enough to make me switch to tar!

Even if all cpios were fixed to look properly at all 18 bits, the problem will
recur with tomorrow's filesystems.  Let us not perpetuate an inode number limit
that is too low.

Volume-Number: Volume 11, Number 37

From jsq  Sat May 30 21:41:51 1987
Posted-Date: 28 May 87 17:31:30 GMT
Received-Date: Sat, 30 May 87 21:41:51 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA11747; Sat, 30 May 87 21:41:51 CDT
From: Jim Mayer <[e-mail]>
Newsgroups: comp.std.unix
Subject: state of unix standards
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Jim Mayer)
Organization: Xerox: Webster Research Center, Rochester, NY
Date: 28 May 87 17:31:30 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Jim Mayer)

I remember hearing at one point about a decision by AT&T and one or more other
companies (Sun Microsystems sticks in my head) to move towards a single
Un*x standard.  Does anyone know what is happening with this?  Is it all
waiting on the "posix" stuff?  Is there any hope of getting a single
standard with:

    Long file names
    Symbolic links
    Reasonable networking
    Long identifier names in programs

[ POSIX does not deal with most of this:  it is strictly a programming
interface standard.  There are related groups dealing with most of these
issues, however:  see my semi-monthly posting on standards groups.  -mod ]

I have not been following the various standards efforts.  I think it might
be useful for someone who has to make a posting describing the major
differences between the different candidates.

[ Appendix A of POSIX is a diff between it and the SVID.  There is no
similar document for it and 4.3BSD.  The X/OPEN people have submitted
a document to P1003.1 on differences between POSIX and X/OPEN.  There
has been no direct comparison document between System V and 4.3BSD for
several years.  -mod ]


--
(Grapevine) mayer.wbst            (Arpa) [e-mail]
(NS) mayer:wbst128:xerox        (Phone) [phone]
(UUCP) rochester!rocksanne!mayer

Volume-Number: Volume 11, Number 38

From jsq  Sat May 30 21:46:24 1987
Posted-Date: 27 May 87 23:10:23 GMT
Received-Date: Sat, 30 May 87 21:46:24 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA11814; Sat, 30 May 87 21:46:24 CDT
From: Henry Spencer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar or cpio?
Message-Id: <[e-mail]>
References: <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 27 May 87 23:10:23 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Henry Spencer)

Andy's comments about the facilities offered by tar and cpio are worthy
of note, but irrelevant to the P1003.1 issues.  This was actually raised
at the original /usr/group standards meeting when the question of a
standard intercharge format came up:  the facilities offered by the
current programs are quite irrelevant to the choice of format, since
the format does not dictate the user interface.  It is not especially
difficult to write "cpar" or "tpio", to get one user interface with the
other format.

I thought the choice of tar by /usr/group was a huge win, and still think
so; the extensions added in the Trial Use Standard strengthen this view.

The cpio binary format is a travesty:  unportable, non-extensible (for
example, it is sure that inode numbers are only 16 bits, often not true
today), and generally a mess.  Cpio ASCII format is better, but it still
shares some of these problems, since its field widths are sized to fit
old systems (for example, it can't deal with 32-bit inode numbers either).

Furthermore, I would note that at least the cpio binary format, possibly
the ASCII one as well, has existed in two different versions.  People who
claim that cpio is older than tar are half-lying:  the current version of
cpio is not.  I submit that the mere existence of multiple incompatible
versions of the cpio format is a major black mark against it.  Tar format
is virtually universal, with only minor (compatible!) extensions having
been made here and there.

Andy makes a good point about extensibility.  The tar format extends
gracefully because it has extra room in its header (which the existing
programs helpfully zero rather than filling with random trash) and in its
file-type code space.  (Note that the Trial Use Standard explicitly
reserves certain type codes for local extensions, and others for future
standards.  Note also that the Trial Use Standard's own extensions are
upward-compatible with the existing format and existing programs.)

Chapter 10 of the Trial Use Standard is a valuable part of the standard,
it is not broken, and it does not need fixing.  Leave it there.

                Henry Spencer @ U of Toronto Zoology
                {allegra,ihnp4,decvax,pyramid}!utzoo!henry


Volume-Number: Volume 11, Number 39

From jsq  Sat May 30 21:57:23 1987
Posted-Date: 27 May 87 16:30:05 GMT
Received-Date: Sat, 30 May 87 21:57:23 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA11928; Sat, 30 May 87 21:57:23 CDT
From: Rahul Dhesi <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: More tar/cpio
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: bsu-cs![e-mail] (Rahul Dhesi)
Organization: CS Dept, Ball St U, Muncie, Indiana
Date: 27 May 87 16:30:05 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Rahul Dhesi)

I think one issue that needs to be clarified is:  Are we trying to standardize
the user interface of the tar/cpio/other interchange standard, or the archive
format, or both?  For example, although standard tar does not accept filenames
from standard input, that is irrelevant to the actual suitablity of its
archive format.  The POSIX standard could easily use the tar archive format
with the cpio command structure, or vice versa.

[ POSIX is a programming interface standard.  It has nothing to do with
the command interface.  As such, the data interchange format is appropriate
for POSIX to standarize, but the user interface of the command that implements
it is not.  While P1003.2 (Shell and Tools) might be interested in the
user interface, P1003.1 (POSIX) is not.  -mod ]

The obvious choice seems to be the tar archive format (more widely used and
available) with cpio's user interface.

[ The user interface is irrelevant to P1003.1 and POSIX.  The immediate
issue (that must be resolved before balloting on the POSIX Full Use Standard)
is what the data interchange format should be.  Input before the next
P1003.1 Working Group meeting (20-24 June 1987 in Seattle) would be
most helpful.  -mod ]

--
Rahul Dhesi         UUCP:  {ihnp4,seismo}!{iuvax,pur-ee}!bsu-cs!dhesi

Volume-Number: Volume 11, Number 40

From jsq  Mon Jun  1 21:25:18 1987
Posted-Date: 2 Jun 87 02:25:08 GMT
Received-Date: Mon, 1 Jun 87 21:25:18 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA16036; Mon, 1 Jun 87 21:25:18 CDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: tar vs. cpio
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 2 Jun 87 02:25:08 GMT
Apparently-To: std-unix-archive
Status: R

Included below is a draft proposal for IEEE P1003.1 regarding
the recently raised issue of Archive/Data Interchange Format.
I will deliver a proposal resembling it to P1003.1 at their
next meeting, which is three weeks from today, in Seattle.

Note two things:  this is a proposal for P1003.1, not P1003.2,
or any other group; if you disagree with my conclusions, you
can submit your own proposal-- the address is below.

If you agree with my approach but think it needs adjusting,
you can send me mail or submit articles.  If you disagree, you
can also do those things.



                                  tar vs. cpio      IEEE P1003.1 N.___
                                                           1 June 1987

                               John S. Quarterman

                    Institutional Representative from USENIX
                                   usenix!jsq



          Secretary, IEEE Standards Board
          Attention: P1003 Working Group
          345 East 47th St.
          New York, NY 10017

          In both the Trial Use Standard and Draft 10, POSIX sS10.1
          describes a data interchange format based on the tar
          program.  That section has appeared in every draft of IEEE
          1003.1 in some form and has always been based on tar format.
          The P1003.1 Working Group has recently received two related
          proposals regarding that section: one to add cpio format
          (including old-style, non-ASCII (non c option) format);
          <N.048 Lorraine C. Kevra> <V11N14> <V11N25 Eric S. Raymond>
          the other to replace the existing tar-based format with cpio
          format.  <N.043 X/OPEN> <V11N13> Some clarifications were
          received to the former.  <N.064 Dominic Dunlop> <V11N15> It
          was also proposed verbally in the latest Working Group
          meeting to drop sS10.1 altogether and let P1003.2 handle the
          issue.  <V11N08> <V11N11> <V11N09 Guy Harris> <V11N12 Doug
          Gwyn>

          The present note is a response to those proposals.  Much of
          the detail in it is derived from articles posted in the
          USENET newsgroup comp.std.unix.  Those articles are
          referenced with this format: <V11N09 Guy Harris> which gives
          the volume (11) and number of the article, and the name of
          the submittor.  If no submittor name is given, the posting
          was by the moderator, John S. Quarterman.  Thanks to those
          who submitted articles.  However, the content of this note
          is solely the responsibility of the author.

          There are a number of problems with both cpio formats.
          First, those related to the non-ASCII format:

            1.  Numerous parameters, including inode numbers, mode
                bits, and user and group IDs, are kept in two-byte
                binary integers.  This has historically produced
                serious byte-order problems when data is moved among
                systems with different byte orders.  <V11N09 Guy
                Harris>

            2.  The byte-swapping and word-swapping options to the
                cpio program are inadequate patches; with an ASCII
                format the problem would not be present.  The options
                are not consistent across versions of the program: in







          Page 2                  tar vs. cpio      IEEE P1003.1 N.___



                System III, data blocks and file names are byte
                swapped; in System V, only data blocks are byte
                swapped.  <V11N09 Guy Harris>

            3.  The two-byte integer format limits the range of inode
                numbers to 1..65535.  Many current file systems are
                bigger than that.  <V11N37 Paul Eggert> <V11N39 Henry
                Spencer>

          Non-ASCII cpio format is clearly not portable and should not
          even be considered for standardization.  <V11N12 Doug Gwyn>

          There are several problems that occur even with the ASCII
          cpio format:

            1.  Many implementations of cpio only look at the lower 16
                (or even 15) bits of the inode number, even in ASCII
                format.  <V11N39 Henry Spencer> This is because the
                variable that is used to contain the value is declared
                to be unsigned short, just as in binary format.  Thus,
                even though ASCII cpio format does not constrain this
                number, it is still less than portable.  <V11N37 Paul
                Eggert>

            2.  The proposed cpio ASCII format as specified, <N.048
                Lorraine C. Kevra> <V11N14> is not portable because
                the proposal assumes that sizeof(int) == sizeof(long).
                <N.064 Dominic Dunlop> <V11N15>

            3.  The file type written in a numerical format, making it
                UNIX specific rather than POSIX specific, since POSIX
                (and tar) specifies symbolic, rather than numerical,
                values for file types.  <V11N09 Guy Harris>

            4.  Hard links are not handled well, since cpio format
                does not record that two files are linked.  If two
                files that are linked are written in cpio format, two
                copies will be written.  There is an option to the
                cpio program to detect duplicate files by matching
                pairs of (h_dev, h_ino) and producing links, but that
                is done after the fact.  <V11N09 Guy Harris> (There is
                a program, afio, that handles cpio format more
                efficiently in this and other cases than the licensed
                versions of the program.) <V11N21 Chuck Forsberg>

            5.  Symbolic links are not handled at all, and no type
                value is reserved for them.  This makes cpio useless
                on a large class of historical implementations (those
                based on 4.2BSD or its file system) for one of the
                main purposes of POSIX sS10.1: archiving files for
                later retrieval and use on the same system.







          Page 3                  tar vs. cpio      IEEE P1003.1 N.___



            6.  The cpio format is less common than tar format: there
                are few historical implementations from Version 7 on
                that do not have tar; there are many that do not have
                cpio.  <V11N09 Guy Harris> <V11N10 Charles Hedrick>
                <V11N24 Jim Cottrell> It is true that cpio (non-ASCII
                format) was invented before tar, <V11N22 Joseph S. D.
                Yao> apparently in PWB System 1.0.  <V11N26 Joseph S.
                D. Yao> However, cpio was not available outside AT&T
                before the release of System III, while tar was in
                wide use with Version 7 and is still much more common.
                Also, it appears that the cpio format of PWB was not
                the same as that of System III.  <V11N39 Henry
                Spencer> Although System III and perhaps early
                releases of System V did not include tar, <V11N26
                Joseph S. D. Yao> current releases of System V do.

            7.  It is very late in the process to propose that P1003.1
                adopt cpio format now, especially considering that it
                was originally proposed to and rejected by the
                /usr/group committee before P1003.1 was even formed.
                <V11N39 Henry Spencer>

          There are several advantages to the current tar-based format
          as specified in sS10.1:

            1.  There are no byte- or word-swapping issues caused by
                the format, since all the header values are ASCII byte
                streams.  <V11N17 John Gilmore>

            2.  There are no inode numbers recorded, and file types
                are kept in symbolic form, so the format is less
                implementation-specific than cpio format.  <V11N17
                John Gilmore>

            3.  Historical tar format is the most widely used, as
                discussed in 6. above, despite apparent assertions to
                the contrary.  <N.043 X/OPEN> <V11N13>

            4.  The format specified in sS10.1 is upward-compatible
                with tar format.  Old tar archives can be extracted by
                a program that implements sS10.1.  Archives using some
                of the extensions of sS10.1 can be extracted with old
                (Version 7) tar programs, although symbolic links will
                not be extracted and contiguous files will not be
                handled properly (cpio does not handle these
                capabilities at all).  Files with very long names will
                not be handled properly (cpio does no better at this).
                All tar implementations are compatible to this extent.
                <V11N17 John Gilmore>









          Page 4                  tar vs. cpio      IEEE P1003.1 N.___



            5.  The /usr/group working group and P1003.1 have already
                done the work <P.061> <M.019 5.1.121 Pg.13> <RFC.003
                #121> <P.038> <P.006> required to add optional
                extensions (such as symbolic links, contiguous files,
                and long file names) that are needed on many
                historical implementations and that cpio format lacks.

            6.  The format is extensible for future facilities.
                <V11N39 Henry Spencer>

            7.  There is a public domain implementation of the format
                of sS10.1.  That implementation provided feedback which
                led to improvements in the current specification, and
                has been in use for years in transferring data with
                licensed tar implementations.  <V11N17 John Gilmore>

            8.  Many people prefer the user interface of the cpio
                program to that of the tar program, because the former
                can accept a list of pathnames to archive on standard
                input while the latter takes them as arguments,
                limiting the length of the list.  <V11N34 Andrew
                Tannenbaum> However, the above-mentioned public domain
                implementation of tar accepts pathnames on standard
                input.  <V11N17 John Gilmore> <V11N19 Jim Cottrell>
                Diffs to standard tar to add an option to accept
                pathnames on standard input when creating an archive
                have also been posted to USENET.  <V11N36 John
                Gilmore> The user interface is, in any case,
                irrelevant to P1003.1.  <V11N39 Henry Spencer> <V11N40
                Rahul Dhesi>

          There are some problems that neither tar nor cpio handles
          well.

            1.  An option to prevent crossing mount points would be
                useful for backups.  <V11N19 Jim Cottrell> <V11N22
                Joseph S. D. Yao> However, this appears to be more of
                an implementation issue than a format issue, <V11N28
                Dave Brower> <V11N32 Joseph S. D. Yao> especially
                considering that there are options to find in 4.2BSD,
                <V11N24 Jim Cottrell> SunOS 3.2, <V11N36 John Gilmore>
                and System V Release 3.0 <V11N35 Mike Akre> that take
                care of this.

            2.  The default block size in many tar implementations is
                too large for some tape controllers to read <V11N27
                Rob Lake> (the 3B20 has this problem).  This is not a
                problem with the interchange format, however.

          There is nothing that the proposed cpio can handle that the
          tar-based format already in POSIX sS10.1 cannot handle; in







          Page 5                  tar vs. cpio      IEEE P1003.1 N.___



          fact, the former is less capable.  If cpio format were
          augmented to handle missing capabilities, it would be
          subject to the same objections now aimed at the format given
          in sS10.1: that it was not identical with an existing format.

          There is no advantage in replacing the current tar-based
          format of sS10.1 with cpio format.  There is also no
          advantage in adding cpio format, because two standards are
          not as good as a single standard.

          Some have recommended removing sS10.1 from POSIX altogether,
          <V11N12 Doug Gwyn> perhaps with a recommendation for P1003.2
          to pick up the idea.  <V11N09 Guy Harris> While I believe
          that that would be preferable to adding cpio format, whether
          or not tar format remains, I recommend leaving sS10.1 as it
          is, because

             o+ The inclusion of an archive/interchange file format is
               in agreement with the purpose of POSIX to promote
               portability of application programs across interface
               implementations.  Some format will be used.  It is to
               the advantage of the users of the standard for there to
               be a standard format.

             o+ The de facto standard is tar format.  The current sS10.1
               standardizes that, and provides upward-compatible
               extensions in areas that were previously lacking.

          The Archive/Interchange File Format should be left as it is.

                                                  Thank you,



                                                  John S. Quarterman






Volume-Number: Volume 11, Number 41

From jsq  Tue Jun  2 10:43:13 1987
Posted-Date: 2 Jun 87 08:04:10 GMT
Received-Date: Tue, 2 Jun 87 10:43:13 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA25539; Tue, 2 Jun 87 10:43:13 CDT
From: Tony O'Hagan <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar or cpio?
Summary: off-line archives and big files
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Tony O'Hagan)
Organization: Computer Science, Queensland Uni, Australia
Date: 2 Jun 87 08:04:10 GMT
Apparently-To: std-unix-archive
Status: R

From: [e-mail] (Tony O'Hagan)

Last year I wrote an off-line tape archive system for use on our UNIX
machines.  Tar and cpio were carefully compared to decide the appropiate
format for the tape archives.  Eventually we chose cpio because it permitted
retrieval of any pattern of files.

About 120+ cpio files are stored on each archive tape and from bitter
experience I know that sometimes when appending/retrieving files to/from tape
an insufficient number of files are skipped.  (We count them using taprd now)
It would have been useful to write a "file label" included in the header
of each cpio file and be able to check this when reading.  I would have used it
to check the file number but I'm sure it would have other uses.
( I would skip to the file before and check it's label when appending. )

I recently adapted the archive system from V7 to BSD 4.2 and added the
facility to drive remote tape drives using the blocking filters which fitted
in well with cpio.

[ These are useful points, though they are not problems with the data
interchange format, rather with the program that uses it.  -mod ]

    P.S.
There are a few other bugs in cpio which I had to fix for the local version.
    * creating new otherwise unstored directories with the current
      mask (not mode 777).  (with -d switch)
    * not changing the ownership/group/permissions of existing
      directories back to their values at the time of archiving.
==============================================================================
Tony O'Hagan        Australia: [phone]  International: [phone]
University of Queensland    CSNET:    [e-mail]    ACSnet:    [e-mail]
Dept. of Computer Science    UUCP:    ...!seismo!munnari!uqcspe.oz!tony
St. Lucia, Brisbane,         ARPA:    [e-mail]
AUSTRALIA  4067             JANET:    uqcspe.oz!tony@ukc

Volume-Number: Volume 11, Number 42

From jsq  Thu Jun  4 17:09:57 1987
Posted-Date: 2 Jun 87 17:15:32 GMT
Received-Date: Thu, 4 Jun 87 17:09:57 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA11054; Thu, 4 Jun 87 17:09:57 CDT
From: <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: "Gregg Townsend" <[e-mail]>
Date: 2 Jun 87 17:15:32 GMT
Apparently-To: std-unix-archive

From: <[e-mail]> (Gregg Townsend)

I agree with you on this and appreciate the effort it took to collect
all the various points in a single document.  Here is one additional
point about the ASCII cpio format that I think is worth mentioning:

    n.  Even when a cpio archive is composed entirely of text
        files, it can be tricky to transport because the file
        name is terminated by a 00 byte.


Hope this is helpful.  Do with it what you wish.

     Gregg Townsend / Computer Science Dept / Univ of Arizona / Tucson, AZ 85721
     [phone]      [e-mail]       110 57 17 W / 32 13 47 N / +758m

Volume-Number: Volume 11, Number 43

From jsq  Thu Jun  4 17:21:00 1987
Posted-Date: 2 Jun 87 02:55:52 GMT
Received-Date: Thu, 4 Jun 87 17:21:00 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA11401; Thu, 4 Jun 87 17:21:00 CDT
From: Mark Horton <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: More tar/cpio
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Mark Horton)
Organization: AT&T Bell Laboratories, Columbus, Oh
Date: 2 Jun 87 02:55:52 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Mark Horton)

In article <[e-mail]> [e-mail] (John Gilmore) writes:
>*    People like cpio's user interface better.
>
>*    Tar's format on the tape is more portable.

Personally, I feel exactly the opposite.

The cpio format is quite portable, as long as you're careful to use
the c option.  The advantage to cpio format is that the images created
are considerably smaller than tar's.  Also, cpio can save/restore entries
from /dev, making it useful for backups.

[ The format in POSIX 10.1 can also do this.  -mod ]

The user interface, on the other hand, of cpio is horrible, unless you
are trying to do an incremental backup.  Compare the following equivalent
commands:
    $ tar c .
    $ find . -print | cpio -oc > /dev/rmt8

    $ tar x .
    $ cpio -icd < /dev/rmt8

Not only do you need a find command with cpio, but you'd better
remember the c and d options, or you'll regret it later!

cpio is a big win for incremental backups, as long as they fit
on one reel of tape:
    $ find . -newer /etc/lastbackup -print | cpio -oc > /dev/rmt8
Of course, that's a pretty major "as long as", and there are lots
of special versions of cpio that understand multiple backup volumes
and streaming I/O and such things.

    Mark

Volume-Number: Volume 11, Number 44

From jsq  Thu Jun  4 17:31:07 1987
Posted-Date: 2 Jun 87 18:35:19 GMT
Received-Date: Thu, 4 Jun 87 17:31:07 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA11616; Thu, 4 Jun 87 17:31:07 CDT
From: Guy Harris <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Guy Harris)
Date: 2 Jun 87 18:35:19 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Guy Harris)

I agree with the proposal; these are just some nits.

          ...meeting to drop sS10.1 altogether...

The sequence "s^HS" appears here, and in several other places - is
this intentional or a bizarre result from "nroff"?

[ It's nroff's attempt to produce a section sign.  The actual note
will be formatted with troff, which can handle it.  I will incorporate
your other comments.  -mod ]

            4.  Hard links are not handled well, since cpio format
                does not record that two files are linked.  If two
                files that are linked are written in cpio format, two
                copies will be written.  There is an option to the
                cpio program to detect duplicate files by matching
                pairs of (h_dev, h_ino) and producing links, but that
                is done after the fact.

Actually, this is the standard way "cpio" handles hard links; it's
not an option.

            5.  Symbolic links are not handled at all, and no type
                value is reserved for them.  This makes cpio useless
                on a large class of historical implementations (those
                based on 4.2BSD or its file system) for one of the
                main purposes of POSIX sS10.1: archiving files for
                later retrieval and use on the same system.

(Another s^HS here)  It is possible to extend this format to handle
symbolic links; we have done this.

[ But remember that what was proposed to P1003.1 was existing System V
cpio format. -mod ]

                ...However, cpio was not available outside AT&T
                before the release of System III, while tar was in
                wide use with Version 7 and is still much more common.

Actually, the old "cpio" was available with PWB/UNIX 1.0, which AT&T
did release.

                Also, it appears that the cpio format of PWB was not
                the same as that of System III.  <V11N39 Henry
                Spencer> Although System III and perhaps early
                releases of System V did not include tar, <V11N26
                Joseph S. D. Yao> current releases of System V do.

No, System III and all releases of S5 included "tar".

Volume-Number: Volume 11, Number 45

From jsq  Thu Jun  4 17:41:05 1987
Posted-Date: 1 Jun 87 13:16:00 GMT
Received-Date: Thu, 4 Jun 87 17:41:05 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA11752; Thu, 4 Jun 87 17:41:05 CDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: Re: More tar/cpio
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
Date: 1 Jun 87 13:16:00 GMT
Apparently-To: std-unix-archive

From: <ihnp4!gorgo!bsteve> (Steve Blasingame)

[e-mail] (Rahul Dhesi) Writes:

>The obvious choice seems to be the tar archive format (more widely used and
>available) with cpio's user interface.

The significant issue regarding cpio that has not been addressed is the
function of copying directory trees to directory trees. There is not another
standard tool that performs this important function.

[ I use tar to do this all the time.  The 4.3BSD man page includes:

               Tar can also be used to move
               hierarchies with the command
                 cd fromdir; tar cf - . | (cd todir; tar xf -)

-mod ]

  Steve Blasingame (Oklahoma City)
  ihnp4!gorgo!bsteve

Volume-Number: Volume 11, Number 46

From jsq  Thu Jun  4 18:58:01 1987
Posted-Date: 3 Jun 87 17:53:08 GMT
Received-Date: Thu, 4 Jun 87 18:58:01 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA13169; Thu, 4 Jun 87 18:58:01 CDT
From: Andrew Tannenbaum <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]@ima.ISC.COM (Andrew Tannenbaum)
Organization: Interactive Systems, Boston, MA
Date: 3 Jun 87 17:53:08 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Andrew Tannenbaum)

>            6.  ...
>        <V11N39 Henry Spencer> Although System III and perhaps
>        early releases of System V did not include tar, <V11N26
>        Joseph S. D. Yao> current releases of System V do.

User manuals for UNIX Release 3.0 (June 1980) and Release 5.0 (June
1982) both contain (identical) tar man pages.  The changes between the
V7 (January 1979) tar man page and these two seem to be cosmetic.  Both
contain cpio man pages, the 5.0 cpio has the byteswapping options, 3.0
does not.

This doesn't mean that Sys III and Sys V had tar, but it does indicate
an intention to include them.

    Andrew Tannenbaum   Interactive   Boston, MA   [phone]

Volume-Number: Volume 11, Number 47

From jsq  Thu Jun  4 19:08:15 1987
Posted-Date: 2 Jun 87 04:43:42 GMT
Received-Date: Thu, 4 Jun 87 19:08:15 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA13375; Thu, 4 Jun 87 19:08:15 CDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: Re: tar or cpio?
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Reply-To: scgvacd!stb![e-mail] (Michael Gersten)
Organization: STB BBS, La, Ca, USA, 90402
Date: 2 Jun 87 04:43:42 GMT
Apparently-To: std-unix-archive

From: seismo!scgvacd!stb!michael (Michael Gersten)

I have some comments on Tar/Cpio.

First, Radio SHack does sell a tar that has an argument F for "here is a
file with the files you should read". Works with - for stdin. However,
you can't read the files from stdin and write the output to stdout,
although you can write to a named pipe (does mostly the same thing).

Secondly, whatever you use for backups should know about blocksizes.
In particular, if you lose one floppy, users should be able to restore all
the information on the other floppies. Tar does not do this--linking information
gets lost if this occurs.

In particular,
    Floppy A has file X on it
    Floppy B has "Link X to Y"
If you lose floppy A, you've got garbage for Y. Worse, if you restore out
of order, no warning is given other than "Cannot link".

Finally, I feel that tar, in order to be usable as a backup facility, should
be required to unlink a file before it restores it. Otherwise, consider this:

Customer uses initialization floppy to initialize hard disk, which puts basic
commands (ls, tar, cp, etc) on disk, then restores the entire system from tarred
floppies.

Initialization system had /bin/l linked to /bin/ls (AT&T versions)
Customer had /bin/ls linked to lc, lf, lx (Berkeley versions), and the
AT&T as ls.old

After untarring, the Berkeley version was lost, and the AT&T version was under
all the names. Took me a while to figure this one out. Guess who the
customer was.

I do not consider backup/restore usable as they take 5 minutes per file to
recover individual files. I am not kidding; maybe R/S mucked something, but
that is ridiculus. Sure, you can get faster, but only if you first format the
disk, which takes 2 hours, and also do an incremental dump first.

[ Do you mean dump and restor?  (Or dump and restore?)  -mod ]

---
: Michael Gersten        seismo!scgvaxd!stb!michael
: The above is the result of being educated at a school that discriminates
: against roosters.

Volume-Number: Volume 11, Number 48

From jsq  Thu Jun  4 19:20:03 1987
Posted-Date: 3 Jun 87 20:16:23 GMT
Received-Date: Thu, 4 Jun 87 19:20:03 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA13581; Thu, 4 Jun 87 19:20:03 CDT
From: Jerry Schwarz <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Jerry Schwarz)
Organization: AT&T Bell Labs, Murray Hill
Date: 3 Jun 87 20:16:23 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Jerry Schwarz)

One problem with tar format is that it has a fixed 100 character
limit on the length of pathnames.   While this may not have
been a problem in practice, it would be short sighted to adopt
a standard with this limitation.

[ The format in POSIX 10.1 has a way of handling longer file names. -mod ]

Jerry Schwarz

Volume-Number: Volume 11, Number 49

From jsq  Fri Jun  5 16:09:15 1987
Posted-Date: 5 Jun 87 18:04:28 GMT
Received-Date: Fri, 5 Jun 87 16:09:15 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA03356; Fri, 5 Jun 87 16:09:15 CDT
From: Michael MacDonald <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail]
Date: 5 Jun 87 18:04:28 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Michael MacDonald)

    I have just finished working on a CPIO tape reader and approx 1 year
ago a TAR tape reader for our IBM3090 180/vf running MVS/XA.

   The following comments may be of interest as they come from a slightly
different point of view. I do not have significant *ix experience and
the following comments come as a result of trying to pick apart these tapes
when they are used for data interchange.

   TAR and CPIO are *used* for purposes of backup AND data interchange.

   TAR Format comments.
       1)  Data is written as blocks of 512 bytes. This allows for faster
           processing and this is important for BIG files.
[ Most implementations allow using tape blocks larger than that.  -mod ]
       2)  There is room left in the header. This allows for customization
           by a site while still allowing other sites to read the tape
           without using the customized version (if they do it right).
       3)  The length of the NAME and the LINKNAME field is not enough.
           Extending the length to 256 would extend the header to 2 blocks
           but I think that extending the length outweighs the disadvantages.
[ In addition to

#define NAMSIZ    100
    char    name[NAMSIZ];

POSIX Section 10.1 also has

#define PFXSIZ    155
    char    prefix[PFXSIZ];

which is used when name isn't big enough.  The total of the two is set
to match the minimum permissible value of PATH_MAX.  -mod ]
       4)  All of the tape drives that I have worked with (not that many)
           are capable of writing a short block. If TAR would recognize
           a physical end of file rather than two blocks of hex 00's.
           This would solve a number of problems with TAR.
       5)  Limited amount of Unix dependent information in the header.
           If a *backup* system is used for data interchange is it really
           necessary to add many Operating System dependent features.
           Are the advantages gained by using these dependencies *really*
           advantages even in a backup system?

   CPIO Format comments.
        1)  Data is not block oriented. This slows down processing
            considerably.
        2)  There is no room left in the header. No customization
            possible (without also sending the customized program).
        3)  Is 128 that much better than 100? See TAR note 3.
        4)  The CPIO end of file mark (TRAILER!!!) why not a physical EOF
            See TAR note 4.
        5)  When it comes to OS dependent information the CPIO header is
            full of it.
        6)  After writing the CPIO tape reader I came across a ?serious?
            problem. (The following note is from the unix manual page cpio(4)
            The h_name field is "h_namesize rounded to word" long. The
            header must begin on a word boundary (although not documented).
            The wordsize of the machine is not a CPIO option (as far as I can
            tell). This means CPIO tapes cannot be read on a machine with
            a different wordsize. I question if this "feature" should be
            standardized without at least a wordsize option.

 Michael MacDonald
 Software Specialist, School of Computer Science
 University of New Brunswick
 Po. Box 4400
 Fredericton, New Brunswick
 CANADA    E3B 5A3

 [phone]

 Netnorth/BITNET: MIKEMAC@UNB

Disclaimer: The opinions stated are mine, no one likes them around here either.

Volume-Number: Volume 11, Number 50

From jsq  Fri Jun  5 16:25:19 1987
Posted-Date: 5 Jun 87 21:25:10 GMT
Received-Date: Fri, 5 Jun 87 16:25:19 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA03795; Fri, 5 Jun 87 16:25:19 CDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Message-Id: <[e-mail]>
References: <[e-mail]>
Reply-To: [e-mail]
Date: 5 Jun 87 21:25:10 GMT
Apparently-To: std-unix-archive

Since the tar and cpio comments keep coming in, I will let them collect
(posting them meanwhile) until about 16 June, after which I will incorporate
them into the note I posted previously and deliver same to IEEE P1003.1.

Volume-Number: Volume 11, Number 51

From jsq  Fri Jun  5 16:59:16 1987
Posted-Date: 5 Jun 87 21:59:06 GMT
Received-Date: Fri, 5 Jun 87 16:59:16 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA04367; Fri, 5 Jun 87 16:59:16 CDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: USENIX, standards BOF
Message-Id: <[e-mail]>
Date: 5 Jun 87 21:59:06 GMT
Apparently-To: std-unix-archive

The 1987 Summer USENIX Conference is next week, 8-12 June, at the
Hyatt Regency in Phoenix, Arizona.  There will be a standards BOF
(Birds of a Feather).  I believe it's Tuesday, 9 June, 6-8PM.
Participants of comp.std.unix are hereby invited.  Potential
topics include anything that has been discussed here, including
tar and cpio, case folding, standards access, and even time zones.

Copies of the draft POSIX Rationale appendix will be available.
I will have at least one copy of POSIX Draft 10, but will not be
distributing copies.  Addresses for the correspondents' lists
and other standards-related information will be available.

Volume-Number: Volume 11, Number 52

From jsq  Sat Jun 13 22:09:31 1987
Posted-Date: 7 Jun 87 17:17:33 GMT
Received-Date: Sat, 13 Jun 87 22:09:31 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA11201; Sat, 13 Jun 87 22:09:31 CDT
From: Bill Jones <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Bill Jones)
Organization: Develcon Electronics, Toronto
Date: 7 Jun 87 17:17:33 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Bill Jones)

In article <[e-mail]> you write:
>                However, cpio was not available outside AT&T
>                before the release of System III, while tar was in
>                wide use with Version 7 and is still much more common.

My memory is fuzzy now, but I recall cpio having been distributed on
the V7 addendum tape, whose other contents were (I think) fsck, the
line printer driver, and a c2 cured of certain overoptimism.  (This is
a nit picked for historical accuracy only:  I believed then, and still
do, that tar is the better format.  I'm not even keen that this should be
posted, especially if you cannot verify the assertion.)
[ Can anybody verify this?  -mod ]
--
Bill Jones, Develcon Electronics, 856 51 St E, Saskatoon S7K 5C7 Canada
uucp:  ...ihnp4!sask!zaphod!billj               phone:  [phone]

Volume-Number: Volume 11, Number 53

From jsq  Sat Jun 13 22:40:51 1987
Posted-Date: 8 Jun 87 13:22:36 GMT
Received-Date: Sat, 13 Jun 87 22:40:51 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA11714; Sat, 13 Jun 87 22:40:51 CDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Summary: don't like this physical eof business
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Reply-To: munnari!yabbie.oz![e-mail] (Ian Donaldson)
Organization: RMIT Comm & Elec Eng, Melbourne, Australia.
Date: 8 Jun 87 13:22:36 GMT
Apparently-To: std-unix-archive

From: seismo!munnari!yabbie.oz!rcodi (Ian Donaldson)

In article <[e-mail]>:
> From: [e-mail] (Michael MacDonald)
>
>     I have just finished working on a CPIO tape reader and approx 1 year
> ago a TAR tape reader for our IBM3090 180/vf running MVS/XA.

Sounds reasonable.  About the same time it would seem, I wrote an implementation
of Tar in Pascal under NOS on a Cyber 170, with 60-bit words.  See comments
below.

> #define PFXSIZ    155
>     char    prefix[PFXSIZ];
>
> which is used when name isn't big enough.  The total of the two is set
> to match the minimum permissible value of PATH_MAX.  -mod ]

I don't agree - there should be no limit to the pathname size.
4.2bsd has a limit of MAXPATHLEN (unfortunately), but it is a reasonable
value (1024).  Probably the reason that was enforced was a side-effect
of the speedups to nami(), using one copyinstr() rather than judicious use
of fubyte().  The code could be tweaked to overcome this limit without
too much trouble no doubt.  V7 and SVR2 don't have any such limit.

100+155 just doesn't seem enough in comparison for Tar, but in practice
it would suffice 99% of the time.

>        4)  All of the tape drives that I have worked with (not that many)
>            are capable of writing a short block. If TAR would recognize
>            a physical end of file rather than two blocks of hex 00's.
>            This would solve a number of problems with TAR.

Yes, but tar is not always used with tapes, and is not always used
with machines that have 8-bit bytes (eg: Cyber).

I have often written tar archives to raw disk partitions.  If you were
to use the OS EOF concept here, it would fail miserably since the archive
is only a fraction of the size of the partition usually.

The implementation of Tar I had on the Cyber worked well but it it would have
been much more complicated to make it recognize a physical EOF half way through
a 60-bit word (yes there are 7.5 8-bit bytes/60 bit word, and thats
how they arrive from the tape-drives or disks).  NOS does provide a
rather perverted way of determing how many unused bits are in the last
word, but that information is typically only available to the assembly
language programmer, or system guru, and is device dependent.

Remember that tar and cpio work with any "file" that you tell them to.
They are not hard-coded for tapes.

>        5)  Limited amount of Unix dependent information in the header.
>            If a *backup* system is used for data interchange is it really
>            necessary to add many Operating System dependent features.

Yes, but remember this is a UNIX archive mechanism.  Thus it should be able
to save/restore files on most UNIX systems.  It was not designed for
other operating systems.  Information that is not common to most
implementations of UNIX is probably not worth putting in the header.
Those implementations that don't support such information can safely
ignore it anyway.
There is no such information there at the moment in Tar headers.
There is an inode/dev pair in cpio's header however, but this is used
for link determination at extract time.

[ We are discussing standardizing a data interchange/archive format
in a standard that its authors explicitly wanted to be implementable
on hosted, i.e., non-UNIX-based, systems.  The inclusion of inode
numbers is a problem for such implementations, especially when it
is not necessary, as demonstrated by the tar format.  -mod ]

>    CPIO Format comments.
>         1)  Data is not block oriented. This slows down processing
>             considerably.

Its a time/space tradeoff.

Ian D.


Volume-Number: Volume 11, Number 54

From jsq  Sat Jun 13 22:45:23 1987
Posted-Date: 9 Jun 87 16:10:54 GMT
Received-Date: Sat, 13 Jun 87 22:45:23 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA11792; Sat, 13 Jun 87 22:45:23 CDT
From: Bob Alexander <[e-mail]>
Newsgroups: comp.std.unix
Subject: UNIX Facilities for Interpreters
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Bob Alexander)
Organization: ISC Systems Corporation, Spokane, Wa.
Date: 9 Jun 87 16:10:54 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Bob Alexander)

Modern, memory managed operating systems (like UNIX) have addressed
quite nicely certain special requirements of executable files.  In
particular (1) the file (text and data) need not be loaded into memory
in its entirety to begin executing, and (2) the pages can be shared
among processes that are executing them (both on disk and in memory).

As far as I know, those capabilities are not made available to
interpreters for their pseudo-code and data, even though they would be
equally as applicable as they are to "real" programs.  If 15 users are
running a program written in an interpretive language, the interpreter
code is shared, but the p-code exists separately for each user.  This
results in a major disadvantage in the use of interpretive languages to
produce production programs.  Interpretive systems are in quite wide
use today (e.g. shells, SQLs, (((Lisp))), Icon, etc., etc., [even
BASIC]), and as processor speeds increase, use of interpreters will
likely continue to grow.

There are a few ways of working this problem with existing UNIX
facilities, but the ones I've come up with so far are kluges.  My
reason for posting to this newsgroup is to get your reaction to a
possible new UNIX facility for this purpose.  I'll express my
suggestion in SVID format, sort of:

------------------------------

NAME

   vread -- read from a file into memory [but not really, maybe].

SYNOPSIS

   int vread(fildes, bufptr, nbyte)
   int fildes;
   char **bufptr;
   unsigned nbyte;

DESCRIPTION

   The function "vread" attempts to read "nbyte" bytes from the file
   associated with "fildes" into an allocated buffer whose address is
   returned in "bufptr".  This function is similar to read(ba_os)
   [read(ba_os) is SVIDese for read(2)] except for its implications
   concerning virtual memory and that it allocates a buffer rather than
   being given one.

   In a memory managed system, the contents of the file are not
   transferred into the program's memory space.  Instead, the file is
   "mapped" into an area of the caller's data space (involving no
   actual data transfer) and demand-paged into real memory, directly
   from its disk file, as accessed by the program.  As long as any such
   page remains pure, it never needs to be swapped out to disk, and can
   always be swapped in from its original location on disk.  If a page
   becomes dirty, it will have separate swap space allocated for it on
   disk and the page will be re-mapped to that space.  [This technique
   is often used for the initialized data portion of executing
   programs].

   Therefore, "vread" produces the appearance of reading from a file
   into memory, but no data actually transferred (in a memory managed
   system), and the system is afforded the opportunity to optimize by
   sharing the data among all processes accessing the file.  From the
   program's point of view, this operation is indistinguishable from an
   actual data transfer.  In non-memory-managed versions of UNIX,
   "vread" is implemented as a true data transfer.  Therefore, "vread"
   calls are portable between memory-managed and non-memory-managed
   systems.

   Since the system decides the address at which the space will be
   allocated, specific memory management requirements (such as page
   size and alignment) are hidden from the caller and are therefore of
   no concern to a program using this facility.

   In a memory managed system, use of "vread" can provide a significant
   optimization when large portions of files must be available in their
   entirety, but are sparsely and/or randomly accessed (such as the
   pseudo-code for an interpreter), and when it is desirable to share
   large, read-only files.

RETURN VALUE

   Same as read(ba_os).

ERRORS

   Same as read(ba_os).

-------------------------------------

For interpreters to take full advantage of this facility, they would
have to interpret their p-code "as is" as it sits on disk.  If they
modify the code, much of the advantage would be lost.

I'd be interested in hearing your comments and suggestions regarding
this idea; alternative ideas to solve this problem, ways other OSs have
dealt with it, implementation problems, or gross oversights.  What
would you think of a "read only" option for this function (a fourth
argument?), where the data would be mapped as read only (i.e.
protected).
--

Bob Alexander       ISC Systems Corp.  Spokane, WA  [phone]
           UUCP: ihnp4!tektronix!reed!iscuva!boba



Volume-Number: Volume 11, Number 55

From jsq  Sat Jun 13 22:51:11 1987
Posted-Date: 11 Jun 87 13:28:37 GMT
Received-Date: Sat, 13 Jun 87 22:51:11 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA11886; Sat, 13 Jun 87 22:51:11 CDT
From: William E. Davidsen Jr <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Keywords: tar cpio
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (William E. Davidsen Jr)
Organization: General Electric CRD, Schenectady, NY
Date: 11 Jun 87 13:28:37 GMT
Apparently-To: std-unix-archive

From: [e-mail] (William E. Davidsen Jr)

In article <[e-mail]>:
>From: [e-mail] (Michael MacDonald)
>   TAR Format comments.
I realize this hasn't stopped some people, but I will pass on tar
comments because I'm not an expert.

>
>   CPIO Format comments.
>        1)  Data is not block oriented. This slows down processing
>            considerably.
I miss this one. It may slow things under MVS, but there's no reason
why reading less physical data should slow things down. Quite the
opposite.

>        2)  There is no room left in the header. No customization
>            possible (without also sending the customized program).
This is a major advantage. Save us from "custom standard' format. The
custom stuff belongs in the *file*, not the format (in my opinion).

>        3)  Is 128 that much better than 100? See TAR note 3.
Although I've never been bitten by this, it could be a problem. I'm not
sure that it justified scrapping a format which is widely used. cpio
does allow dumping from a relative directory if you have a system with
pathnames longer than the files.

>        4)  The CPIO end of file mark (TRAILER!!!) why not a physical EOF
>            See TAR note 4.
cpio will run nicely to other media sice as floppy disk and/or
removable disk packs. Most device drivers don't support any EOF on
these other than the physical size of the media. You can also have
multiple cpio dumps on a single file, although this is most useful when
doing incremental backups.

>        5)  When it comes to OS dependent information the CPIO header is
>            full of it.
We *are* talking about a U*IX standard here. For data interchange
between unlike systems we have the ANSI standard for tapes, which has
been around since at least 1975 because I wrote a driver for it on a
custom o/s. In FORTRAN. Yes, barf!
[ See comments in previous article about what IEEE 1003.1 is. -mod ]

>        6)  After writing the CPIO tape reader I came across a ?serious?
>            problem. (The following note is from the unix manual page cpio(4)
>            The h_name field is "h_namesize rounded to word" long. The
>            header must begin on a word boundary (although not documented).
>            The wordsize of the machine is not a CPIO option (as far as I can
>            tell). This means CPIO tapes cannot be read on a machine with
>            a different wordsize. I question if this "feature" should be
>            standardized without at least a wordsize option.
I confess I don't understand the wording here, but cpio is *not*
limited in this way as far as I can tell. I routinely transfer files
from Xenix (16 bit) to PC/IX (16 bit), to VAX, Sun3, and unix-pc (all
32 bit), and from time to time Cray2 (64 bit). It all works, so I think
the wording is at fault here, not the method.
--
    bill davidsen        ([e-mail])
  {chinet | philabs | sesimo}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me

Volume-Number: Volume 11, Number 56

From jsq  Sat Jun 13 22:54:21 1987
Posted-Date: 13 Jun 87 05:16:33 GMT
Received-Date: Sat, 13 Jun 87 22:54:21 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA11947; Sat, 13 Jun 87 22:54:21 CDT
From: Brian Katzung <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Brian Katzung)
Organization: Lachman Associates, Inc, Chicago
Date: 13 Jun 87 05:16:33 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Brian Katzung)

When I was working at the University of California San Francisco,
I made some simple modifications to tar for use as a backup facility.
As far as I know, this is still the method being used for backup on
that system.

The changes I made were:

    o Incremental mode (accepts file names from standard input
        and directories don't recurse).
    o Stay on the device associated with a disk or directory
        (don't cross mount points).
    o Multi-volume tapes on drives that support EOT reporting
        (I added a simple ioctl to our tape driver that
        reported EOT status).
    o A flag for continuing after directory checksum errors (to
        allow starting with any volume in a multi-volume
        set; it quickly syncs up on the first valid header).
    o Copies of all errors could be sent to a log file for
        semi-unattended operation.

-- Brian Katzung  ihnp4!laidbak!katzung


Volume-Number: Volume 11, Number 57

From jsq  Sat Jun 13 23:09:59 1987
Posted-Date: 14 Jun 87 04:09:48 GMT
Received-Date: Sat, 13 Jun 87 23:09:59 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA12184; Sat, 13 Jun 87 23:09:59 CDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: Access to UNIX-Related Standards
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Moderator, John Quarterman)
Date: 14 Jun 87 04:09:48 GMT
Apparently-To: std-unix-archive

This is the latest in a series of similar comp.std.unix articles.
Corrections and additions to this article are solicited.


Access information is given in this article for the following standards:
IEEE 1003.1 (POSIX), 1003.2 (shell/tools), 1003.3 (verification)
/usr/group working groups on distributed file system, network interface,
    graphics/windows, database, internationalization,
    performance measurements, realtime, security, and super computing
X3H3.6 (display committee)
X3J11 (C language)
/usr/group Standard
System V Interface Definition (SVID, or The Purple Book)
X/OPEN PORTABILITY GUIDE (The Green Book)
4.3BSD Manuals


UNIX is a Registered Trademark of AT&T.
POSIX and IEEE are trademarks of the Institute of Electrical
    and Electronic Engineers, Inc.
X/OPEN is a licensed trademark of the X/OPEN Group Members.


The IEEE P1003 Portable Operating System for Computer Environments Committee
is sometimes known colloquially as the UNIX Standards Committee.
They published the 1003.1 "POSIX" Trial Use Standard in April 1986.
According to its Foreword:

    The purpose of this document is to define a standard
    operating system interface and environment based on the
    UNIX Operating System documentation to support application
    portability at the source level.  This is intended for
    systems implementors and applications software developers.

Published copies are available at $19.95,
with bulk purchasing discounts available.
Call the IEEE Computer Society in Los Angeles

        714-821-8380

and ask for Book #967.  Unfortunately, this only works for multiple copies.
But the following mail address works for single copies:

    IEEE Computer Society
    P.O. Box 80452
    Worldway Postal Center
    Los Angeles, Ca. 90080

Include a check for $19.95 + $4 for shipping and handling.  For UPS
shipping, add another $4.  Or contact:

        IEEE Service Center
        445 Hoes Ln.
        Piscataway, NJ 08854

and ask for "IEEE 1003.1 Trial Use Standard" - stock number SH10546.

The Trial Use Standard will be available for comments for a period
such as a year.  The current target for a Full Use Standard is Fall 1987.
IEEE has initiated the process to have the 1003.1 effort brought into
the International Organization for Standardization (ISO) arena.

Machine readable copies of the Trial Use Standard are not and will
not be available.

There is a paper mailing list by which interested parties may get
copies of drafts of the standard.  To get on it, or to submit comments
directly to the committee, mail to:

        James Isaak
        Chairperson, IEEE/CS P1003
        Digital Equipment    MK02-2/B05
        Continental Blvd.
        Merrimack, NH      03054-0403
        decvax!isaak
        603-884-1913

Sufficiently interested parties may join the working group.

Related working groups are
    group    subject        co-chairs
    1003.2    shell and tools    Hal Jespersen (UniSoft), Don Cragun (Sun)
    1003.3    verification    Roger Martin (NBS), Carol Raye (AT&T)

Inquiries regarding 1003.2 and 1003.3 should go to the same address
as for 1003.1.


The next scheduled meetings of the P1003 working groups are,
in 1987 and 1988:

June    22-26  P1003.[13]  Seattle (changed from USENIX week in Phoenix to
        give us better working attendance)    Host:  CDC
        P1003.2 will not meet in Seattle, due to scheduling
        problems related to the extreme member overlap between
        1003.1 and 1003.2 and the need for 1003.1 to meet all week
        in order to speed finishing the Full Use Standard.
        But there will be a 1003.2 BOF Tuesday, 6/23, 19:00-22:00,
        to exchange information and assess the status of the command
        descriptions distributed in the April meeting.

Sept.    14-18    Framingham, Massachusetts (same time and place as X3J11)
(Sept 7th is Labor day, and that week is ISO TC97 SC22 meeting in Wash DC)

Dec.    7-11    San Diego

April 1988    Possibly Japan or Singapore, depending on potential attendance.

There is also a balloting group (which intersects with the working group).
This is more difficult.  Contact Jim Isaak for details.  I will repost
them in this newsgroup if there is sufficient interest.

Here are some details from Hal Jespersen regarding P1003.2:

The IEEE P1003.2 "Shell and Utilities" Working Group is developing a
proposed standard to complement the 1003.1 POSIX standard.  It will
consist of

    a shell command language (currently planned to be based on the
    Bourne Shell),

    groups of utility programs, or commands,

    programmatic interfaces to the shell (system(), popen()) and
    related facilities (regular expressions, file name expansion,
    etc.)

    defined environments (variables, file hierarchies, etc) that
    applications may rely upon

    tools for installing application programs onto conforming
    systems

which will allow application programs to be developed out of existing
pieces, in the UNIX tradition.  The scope of the standard emphasizes
commands and features that are more typically used by shell scripts or
C language programs than those that are oriented to the terminal user
with windows, mice, visual shells, and so forth.

There has been some controversy in the Working Group about
clarifying the scope of the 1003.2 standard in regard to its
relationship with 1003.1.  The Working Group is attempting to
produce a standard that will assume the structure and
philosophy of a POSIX system is available, but it will not
require a fully conforming implementation as a base.  For
example, it should be feasible to eventually produce a 1003.2
interface on a V7 system, or on a system very close to POSIX,
but missing a few crucial features (as long as the shell and
utilities didn't need them).  However, the proposed standard
will *not* be unnecessarily watered down simply to allow
non-POSIX systems to conform.

The group is currently seeking proposals for groupings of commands that
may be offered by implementors.  As groups are identified, command
descriptions will be solicited.  There is no requirement that the commands
be in System V or BSD today, but they should realistically be commands
that are commonly found in most existing implementations.


There are three Institutional Representatives to P1003:  John Quarterman
from USENIX, Heinz Lycklama from /usr/group, and Martha Nalebuf from X/OPEN.

As the one from USENIX, one of my functions is to get comments from the
USENIX membership and the general public to the committee.  One of the
ways I try to do that is by moderating this newsgroup, comp.std.unix
(formerly known as mod.std.unix).  An article related to this one
appeared in the September/October 1986 ;login: (The USENIX Association
Newsletter).  I'm also currently on the USENIX Board of Directors.
Comments, suggestions, etc., may be sent to

        John S. Quarterman
        Texas Internet Consulting
        Suite 500, Room 31
        Austin Centre
        701 Brazos
        Austin TX 78701-3243
        512-320-9031
        usenix!jsq

For comp.std.unix:
Comments:    ut-sally!std-unix-request [e-mail]
Submissions:    ut-sally!std-unix        [e-mail]

The May/June 1987 issue of CommUNIXations (the /usr/group newsletter)
contains a report by Heinz Lycklama on the /usr/group Technical Committee
working groups which met in January 1987.

If you are interested in starting another working group, contact
Heinz Lycklama:

        Heinz Lycklama
        Interactive Systems Corp.
        2401 Colorado Ave., 3rd Floor
        Santa Monica, CA 90404
        [phone]
        decvax!cca!ima!heinz


Here is contact information for /usr/group working groups as taken from
the CommUNIXations article mentioned above, and updated by later information
from Heinz Lycklama.

/usr/group Working Group on Distributed File System:
    Laurence Brown            Frederick Glover
    AT&T Information Systems    MK02-1/H10
    190 River Road            Digital Equipment Corporation
    Summit, NJ  07933        Continental Boulevard
    201-522-6046            Merrimack, NH  03054-0430
    attunix!bump            603-884-5111
                    decvax!fglover

/usr/group Working Group on Network Interface:
    Steve Albert
    AT&T Information Systems
    190 River Road, Rm. A-114
    Summit, NJ  07901
    [phone]
    attunix!ssa

/usr/group Working Group on Internationalization:
    Karen Barnes
    Hewlett-Packard Co.
    19447 Pruneridge Ave.
    M/S 47U2
    Cupertino, CA 95014
    [phone]

/usr/group Working Group on Graphics/Windows:
    Tom Greene
    Apollo Computer, Inc.
    330 Billerica Road
    Chelmsford, MA  01824
    [phone], ext. 7581

/usr/group Working Group on Realtime:
    Bill Corwin
    Intel Corp.
    5200 Elam Young Pkwy
    Hillsboro, OR 97123
    [phone]

/usr/group Working Group on Database:
    Val Skalabrin
    Unify Corp.
    1111 Howe Ave.
    Sacramento, CA 95825
    [phone]

/usr/group Working Group on Performance Measurements:
    Ram Chelluri            Dave Hinnant
    AT&T Computer Systems        SCI Systems, Inc.
    Room E15B            Ste 325, Pamlico Bldg
    4513 Western Ave.        Research Triangle Pk, NC 27709
    Lisle, IL 60532            [phone]
    [phone]

/usr/group Working Group on Security:
    Steve Sutton            Ms. Jeanne Baccash
    Consultant, Addamax        AT&T UNIX Systems Engineering
    1107 S. Orchard            190 River Road
    Urbana, IL  61801        Summit, NJ  07901
    217-344-0996            201-522-6028
                    attunix!jeanne

/usr/group Working Group on Super Computing:
    Karen Sheaffer            Robin O'Neill
    Sandia National Laboratory    Lawrence Livermore Laboratory
    P.O. Box 969            P.O. Box 5509, L560
    Livermore, CA  94550        Livermore, CA  94550
    415-422-3431            415-422-0973
                    oneill#[e-mail] Co-chair


The X3H3.6 display management committee has recently formed to develop
a model to support current and future window management systems, yet
is not based directly on any existing system.  The chair solicits
help and participation:

        Georges Grinstein
        wanginst!ulowell!grinstein


The Abstract of the 1003.1 Trial Use Standard adds:

    This interface is a complement to the C Programming Language
    in the C Information Bulletin prepared by Technical Committee X3J11
    of the Accredited Standards Committee X3, Information Processing
    Systems, further specifying an environment for portable application
    software.

X3J11 is sometimes known as the C Standards Committee.  Their liaison to
P1003 is

        Don Kretsch
        AT&T
        190 River Road
        Summit, NJ 07901

A contact for information regarding publications and working groups is

        Thomas Plum
        Vice Chair, X3J11 Committee
        Plum Hall Inc.
        1 Spruce Avenue
        Cardiff, New Jersey 08232

The current document may be ordered from

        Global Press
        2625 Hickory St.
        P.O. Box 2504
        Santa Anna, CA 92707-3783
        U.S.A.
        800-854-7179
        [phone] (from outside the U.S., ask for extension 245.)
        TELEX 692 373

Ask for the X3.159 draft standard.  The price is $65.


The /usr/group Standard is a principal ancestor of P1003.1, X/OPEN,
and X3J11.  It may be ordered for $15.00 from:

        /usr/group Standards Committee
        4655 Old Ironsides Drive, Suite 200
        Santa Clara, California 95054
        [phone]


The System V Interface Definition (The Purple Book, or SVID).
This is the AT&T standard and is one of the most frequently-used
references of the IEEE 1003 committee.

        AT&T Customer Information Center
        Attn:  Customer Service Representative
        P.O. Box 19901
        Indianapolis, IN 46219
        U.S.A.

        800-432-6600 (Inside U.S.A.)
        800-255-1242 (Inside Canada)
        317-352-8557 (Outside U.S.A. and Canada)

    System V Interface Definition, Issue 2
    should be ordered by the following select codes:

    Select Code:    Volume:        Topics:
    320-011        Volume I    Base System
                    Kernel Extension
    320-012        Volume II    Basic Utilities Extension
                    Advanced Utilities Extension
                    Software Development Extension
                    Administered System Extension
                    Terminal Volume Interface Extension
    320-013        Volume III    Base System Addendum
                    Terminal Interface Extension
                    Network Services Extension
    307-131        I, II, III    (all three volumes)

The price is about 37 U.S. dollars for each volume or $84 for all three.
Major credit cards are accepted for telephone orders:  mail orders
should include a check or money order, payable to AT&T.


The X/OPEN PORTABILITY GUIDE (The Green Book)
is another reference frequently used by IEEE 1003.

The X/OPEN Group is "Ten of the world's major information system
suppliers" (currently Bull, DEC, Ericsson, Hewlett-Packard, ICL,
NIXDORF, Olivetti, Philips, Siemens, Unisys, and AT&T) who have
produced a document intended to promote the writing of portable
facilities.  They closely follow both SVID and POSIX, and cite
the /usr/group standard as contributing, but X/OPEN's books
cover a wider area than any of those.

The book is published by

        Elsevier Science Publishers B.V.
        Book Order Department
        P.O. Box 1991
        1000 BZ Amsterdam
        The Netherlands

and distributed in the U.S.A. and Canada by:

        Elsevier Science Publishing Company, Inc.
        52 Vanderbilt Avenue
        New York, NY 10017
        U.S.A.

There are currently five volumes:
    1) System V Specification Commands and Utilities
    2) System V Specification System Calls and Libraries
    3) System V Specification Supplementary Definitions
    4) Programming Languages
    5) Data Management

They take a large number of credit cards and other forms of payment.


Finally, 4.2BSD and 4.3BSD have influenced POSIX in a number of areas.
The best reference on them is the 4.3BSD manuals, published by USENIX.
An order form may be obtained from:

        Howard Press
        c/o USENIX Association
        P.O. Box 2299
        Berkeley, CA 94710

        415-528-8649
        {ucbvax,decvax}!usenix!office

4.3BSD User's Manual Set (3 volumes)        $25.00
    User's Reference Manual
    User's Supplementary Documents
    Master Index

4.3BSD Programmer's Manual Set (3 volumes)    $25.00
    Programmer's Reference Maual
    Programmer's Supplementary Documents, Volume 1
    Programmer's Supplementary Documents, Volume 2

4.3BSD System Manager's Manual (1 volume)    $10.00

Unfortunately, there are some license restrictions.
Contact the USENIX office for details.

Volume-Number: Volume 11, Number 58

From jsq  Sun Jun 14 16:53:26 1987
Posted-Date: 14 Jun 87 21:53:15 GMT
Received-Date: Sun, 14 Jun 87 16:53:26 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA23061; Sun, 14 Jun 87 16:53:26 CDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: Re: USENIX, standards BOF
Message-Id: <[e-mail]>
References: <[e-mail]>
Date: 14 Jun 87 21:53:15 GMT
Apparently-To: std-unix-archive

The standards BOF at the Phoenix USENIX last week (mentioned
in Volume 11 Number 52) had a much higher attendance than previous
standards BOFs.  There were about fifty people there, most with
relevant questions, and some with answers.  It is not clear
that everyone was pleased with everything I and others told
them, but I think some now have a better idea of what is going on.

The twenty copies of the Rationale that I made beforehand
disappeared quickly, as did the thirty I made afterward,
and the forty copies of the draft standard.

I do not know to what to attribute this new, higher level
of interest on the part of USENIX attendees, but it was there.

Comments (preferably technical) from attendees?

Volume-Number: Volume 11, Number 52


Volume-Number: Volume 11, Number 59

From jsq  Sun Jun 14 17:13:40 1987
Posted-Date: 14 Jun 87 22:13:32 GMT
Received-Date: Sun, 14 Jun 87 17:13:40 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA23455; Sun, 14 Jun 87 17:13:40 CDT
From: Jim McGinness <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX Portability Workshop
Keywords: USENIX, POSIX, Portability
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Jim McGinness)
Date: 14 Jun 87 22:13:32 GMT
Apparently-To: std-unix-archive

Newsgroups: comp.std.unix, comp.org.usenix
From: [e-mail]

            Preliminary Call for Papers
            POSIX Portability Workshop

This USENIX workshop will bring together system and application
implementors faced with the problems, ``challenges,'' and other
considerations that arise from attempting to make their products
compliant with IEEE Standard 1003.1.

The target dates are 15 and 16 October, 1987, in Berkeley, CA.
The first day will consist of presentations of brief position papers
describing experiences, dilemmas, and solutions.  On the second day we
plan to form smaller focus groups to brainstrom additional solutions,
dig deeper into specific areas, and attempt to forge common approaches
to some of the dilemmas.

Suggestions for topic areas for position papers include:

C Language Issues            Internationalization
Networked/Distributed Implementations    Pipes and FIFOs
Timer Resolution and Ranges        Signals
Job Control, Process Groups        Limits: Documentation and Inquiry
Conformance Verification (IEEE 1003.3)    Security Concerns
Implications for Commands (IEEE 1003.2)    What to do about errno?
Implications for User Interfaces    Terminal Interface

Position papers are needed by 15 August 1987.  Detailed instructions
will be published in a future issue of ;login:, the USENIX Association
Newsletter (and in other appropriate places, such as comp.std.unix)
along with final information on time and place.

For participation information, contact:

            Jim McGinness
            Digital Equipment Corporation
            Continental Blvd. MK02-1/H1O
            Merrimack, NH 03054
            U.S.A.

            [phone]
            decvax!jmcg
            [e-mail]

POSIX and IEEE are trademarks of the Institute of Electrical
    and Electronic Engineers, Inc.

Volume-Number: Volume 11, Number 60

From jsq  Sun Jun 14 22:09:52 1987
Posted-Date: 10 Jun 87 19:04:45 GMT
Received-Date: Sun, 14 Jun 87 22:09:52 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA27981; Sun, 14 Jun 87 22:09:52 CDT
From: Dominic Dunlop <[e-mail]>
Newsgroups: comp.std.unix
Subject: <limits.h> - copy of item posted to comp.unix.wizards
Summary: POSIX is attempting to address this painful area
Keywords: NOFILES, S5R3, POSIX, 1003.1
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Dominic Dunlop)
Date: 10 Jun 87 19:04:45 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Dominic Dunlop)

Agreed that finding out how many files you have to close in order to be
sure you've closed them all is a pain on most implementations of UN*X.
IEEE 1003.1 is attempting to address this and related issues (after they
were highlighted by IBM and others).

The current draft (#10) of 1003.1, which recently dropped
stone-like through my (physical) mailbox, incorporates something that I and
others cooked up at the April Toronto meeting.  The affected section is
2.9, "Numerical Limits".  As the changes have yet to be reviewed by the
working group, they may well be thrown out or heavily modified later this
month.

Basically what the draft says is that things like OPEN_MAX, the maximum
number of files that a process can have open at any given time, are defined
in a header file, <limits.h>, as "bounded ranges".  OPEN_MAX defines at
compile time the "minimum maximum" number of files that a program can
expect to be able to have open when it runs on a particular
POSIX-conforming implementation (provided that the host system is not
overloaded, that is, in this case, that it hasn't run out of space in its
system open file or inode tables), while OPEN_MAX_CEIL defines the maximum
number of files that any instance of this implementation could ever allow
the program to have open.

What this means to the programmer is that applications may be written so
that they rely on being able to open OPEN_MAX files; so that they run
better if they succeed in opening more files than that (although there's no
point in trying if OPEN_MAX_CEIL are already open); and so that they can be
sure that everything is closed (when spawning children, for example) if they

    for (i = 0; i < OPEN_MAX_CEIL; (void) close(i++));

Thanks for the idea of the bounded range are due to Terence Dowling of Rolm,
who's not on the net.

There's much more of this sort of thing in the draft standard.  The
alternative to this compile-time approach is a run-time library function
which delivers either all possible information (in which case you get a
fixed-size structure, and lose binary application compatibility if in
subsequent releases of a particular POSIX-conforming implementation the
amount of information returned increases); or requested items one at a time
in some sort of union.  If anybody would care to submit a proposal along
these lines to the working group, it is likely that it would be gladly
received.

Copy relevant correspondence to John S Quarterman, moderator for
comp.std.unix.  He can be reached at ut-sally!std-unix.
[ Or [e-mail].  -mod ]

I am
Dominic Dunlop    Phone [phone]
Sphinx Ltd.    UKnet [e-mail]

POSIX is a trademark of the IEEE

Volume-Number: Volume 11, Number 61

From jsq  Sun Jun 14 22:16:04 1987
Posted-Date: 14 Jun 87 20:09:29 GMT
Received-Date: Sun, 14 Jun 87 22:16:04 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA28110; Sun, 14 Jun 87 22:16:04 CDT
From: Guy Harris <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Guy Harris)
Date: 14 Jun 87 20:09:29 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Guy Harris)

> My memory is fuzzy now, but I recall cpio having been distributed on
> the V7 addendum tape, whose other contents were (I think) fsck, the
> line printer driver, and a c2 cured of certain overoptimism. ...
> [ Can anybody verify this?  -mod ]

No, but I think I can refute it with a reasonable degree of accuracy.
It's been a while since I've seen the V7 addendum tape, but I don't
remember "cpio" being on it.  (There were other things, like a
beefed-up F77, some fixes to "fgrep", and a newer version of "awk".
The versions that came with various 4BSD releases seemed to be the V7
addendum tape versions; "cpio" didn't come with any 4BSD release,
which suggests that "cpio" wasn't on the V7 addendum tape, although
it doesn't indicate it for sure.)

Volume-Number: Volume 11, Number 62

From jsq  Sun Jun 14 22:29:05 1987
Posted-Date: 11 Jun 87 19:08:56 GMT
Received-Date: Sun, 14 Jun 87 22:29:05 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA28308; Sun, 14 Jun 87 22:29:05 CDT
From: Joseph S. D. Yao <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Summary: I don't think I said that.
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: hadron![e-mail] (Joseph S. D. Yao)
Organization: Hadron, Inc., Fairfax, VA
Date: 11 Jun 87 19:08:56 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Joseph S. D. Yao)

John,

Thanks for an excellent summary.  However, I don't think I ever
said that System III or System V didn't have tar.  I don't have
an archive to check, but that may have been when I posited that
V7 distribution tapes probably did not come in tar format, since
prior to that tar had not been distributed.  System V may have
had tar from the beginning.  I do not remember about System III.

Berkeley 4BSD tapes did come in tar format, I remember; but they
assumed that you had already received your V7/32V tapes, and were
in a different format from the V7/32V tapes.
[ You're evidently referring to some pretty old BSD tapes. -mod ]

Once tar had come out, versions were written which could read
tar distribution tapes under V6 and PWB 1.0.  (PWB was released
outside of AT&T, BTW.)

    Joe Yao        [e-mail] (not yet domainised)
    hadron!jsdy@{seismo.CSS.GOV,dtix.ARPA,decuac.DEC.COM}
{arinc,att,avatar,cos,decuac,dtix,ecogong,kcwc}!hadron!jsdy
     {netex,netxcom,rlgvax,seismo,smsdpg,sundc}!hadron!jsdy

Volume-Number: Volume 11, Number 63

From jsq  Mon Jun 15 23:43:28 1987
Posted-Date: 15 Jun 87 08:50:23 GMT
Received-Date: Mon, 15 Jun 87 23:43:28 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA19970; Mon, 15 Jun 87 23:43:28 CDT
From: (VLD/VMB <[e-mail]>
Newsgroups: comp.std.unix
Subject: open file range
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: Doug Gwyn (VLD/VMB) <[e-mail]>
Date: 15 Jun 87 08:50:23 GMT
Apparently-To: std-unix-archive

From: Doug Gwyn (VLD/VMB) <[e-mail]>

Some implementations may not have any definite upper limit
(at least, nothing less than several thousand) for the number
of open files supported per process.  The minimum guaranteed
number of open files available is useful (for example for
merge sorting), but the maximum number may not be meaningful.

I submitted a proposal to X3J11 that fflush((FILE*)NULL) would
flush ALL output buffers, since there is no other good way to
accomplish that.  It seems that close(-1) might be a similar
solution for POSIX.  (Since nobody is supposed to be doing this
currently, it is available for assigning new semantics to.)

Volume-Number: Volume 11, Number 64

From jsq  Mon Jun 15 23:48:17 1987
Posted-Date: 15 Jun 87 16:24:13 GMT
Received-Date: Mon, 15 Jun 87 23:48:17 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA20064; Mon, 15 Jun 87 23:48:17 CDT
From: Rick Adams <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Summary: cpio was definitely NOT on the v7 addendum tape
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Rick Adams)
Organization: Center for Seismic Studies, Arlington, VA
Date: 15 Jun 87 16:24:13 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Rick Adams)

This is the README file off of the V7 addendum tape.
cpio is clearly not on the tape. Note that the addendum tape
is in TAR format! (That should say something...)

---rick

--------------BEGIN README from V7 addendum---------------------
Addenda to UNIX 7th edition distribution tape, 12/2/80.

Format: tar(1), 800 bpi.

Contents:

    README: this descriptive file.

    lp.c: the missing line printer driver that
          belongs in /usr/sys/dev/lp.c.
          The program comes from PWB, and needs minor
          changes to work in version 7; see comment
          at head of program.

    lpr: a directory containing the lpr utility and
          its daemon lpd.
          See lpr/makefile for instructions on putting it
          together.

    lpd.8: the manual section for the line printer daemon.

    fgrep.c: new source for fgrep(1) corrects certain
          troubles with keys with common prefixes

    c2: directory containing C optimizer cured of
          certain instances of overoptimism.
          The existing C makefile works

    awk: directory with complete new awk processor,
          see README and makefile therein

    tmac.r: macros to simulate old "roff" in "nroff",
          to support -mr option mentioned in roff(1)

    f77: directory with complete new fortran compiler,
          contains makefiles.
          Further improvements to the I/O library have
          been made at UC Berkeley, and may be obtainable
          from them.

    malloc.c: new source for malloc(3) corrects rare bug

    dev: directory with more robust mag tape drivers for /usr/sys/dev

    fsck: directory with new, stringent file system checking
          program and manual section, far superior to old
          [ind]check.  It checks some data not maintained
          by v7, in particular superblock counts; resulting
          complaints are harmless


Other bug fixes:

/usr/sys/h/param.h: CMAPSIZ and SMAPSIZ
    should both be defined as (NPROC/2)
    otherwise trouble will occur with very large
/usr/sys/conf/low.s: replace br7+7. with br7+10.
    memories
/usr/src/cmd/sed/sed0.c: delete continue after
    case '\0' in compile()
/usr/src/cmd/cu.c: args 1 and 2 of some ioctl calls
    may be interchanged
    a ~ may be lacking from references to ECHO or CRMOD
    in case (f == 1) of mode(f)

The following bugs exist, no fix is included.
      (1) adb does not report floating registers correctly
      (2) ldiv, lmod fail with largest negative dividend
          (these implement division of longs in C);
          the division (unsigned)32768/1 also fails
      (3) dump(1) maintains ddate incorrectly.
          This bug is relatively innocuous; it causes
          more dumping than necessary on some occasions.
      (4) join(1) treats null keys as end of file
      (5) sort -t includes the following tab in some field comparisons
      (6) hs(4) is irrevocably lost
      (7) exec writes arguments into swap space with buffered
          I/O, which may happen physically much later, after
          the space has been used for a core image.  The
          solution is to preallocate
          a portion of swap space to this single purpose.
      (8) break is turned into a DEL regardless
          of what the current interrupt character is
      (?) and others, see warranty


Volume-Number: Volume 11, Number 65

From jsq  Tue Jun 16 10:12:11 1987
Posted-Date: 15 Jun 87 19:52:11 GMT
Received-Date: Tue, 16 Jun 87 10:12:11 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA28214; Tue, 16 Jun 87 10:12:11 CDT
From: Kenneth Almquist <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Summary: Tar format makes correct handling of links impossible.
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Kenneth Almquist)
Organization: Bell Labs, Holmdel, NJ
Date: 15 Jun 87 19:52:11 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Kenneth Almquist)

> [ We are discussing standardizing a data interchange/archive format
> in a standard that its authors explicitly wanted to be implementable
> on hosted, i.e., non-UNIX-based, systems.  The inclusion of inode
> numbers is a problem for such implementations, especially when it
> is not necessary, as demonstrated by the tar format.  -mod ]

Several people have suggested that tar's method of handling links is
better than cpio's.  After looking at the tar format, I wondered how
tar could possibly handle links correctly.   A quick experiment showed
that it doesn't.  Try the following:

    > file1
    ln file1 file2
    tar -cf archive file1 file2
    rm file1 file2
    tar -xf archive file2

The second tar command will fail because tar will simply try to create
a link from file1 to file2, but since I only requested that file2 be
extracted file1 does not exist.

I claim that this is a bug in the tar archive format rather than just
the tar program.  Consider what tar must do to function correctly.  Tar
could remember the location of file1 and lseek to it in this particular
example, but in general the input to tar is not a regular file and thus
may not be seekable.  The best bug fix that I could come up with is to
to make tar write the contents of all files that it does not extract
to a temporary file.  This is unsatisfactory because a user who tried
to extract a single file from a 32 megabyte tape would almost certainly
run out of disk space.

So it seems to me that tar cannot be made to handle links correctly
unless the tar archive format is changed.  The cpio format, on the other
hand, allows links to be handled correctly.  The fact that cpio includes
inode numbers is not all that major a problem for non-UNIX based systems.
Since the only thing the inode numbers are used for is resolving links,
a system which does not support (non-symbolic) links can leave garbage
in the inode field when writing tapes.  A system which does have links
but does not have inode numbers can use a sequence number in place of
the inode number.

I recognize that users will very rarely encounter this bug in tar, but
I still view it as a serious problem in a *standard*.  The question is
not whether this bug in tar desperately needs to be fixed (which is
doesn't), but whether it is reasonable to expect vendors selling cpio
to deliberately introduce a bug into cpio.  Unless someone can suggest
a good way to make cpio use the tar format and still work correctly,
vendors will have to do just that to be compatible with the new standard.


I wonder if there is still any chance of a new interchange format that
corrected the deficiencies of both cpio and tar being accepted as the
standard.  Assuming someone could be found to write a public domain
implementation of the new format, would that be sufficient to make it
a reasonable alternative to the existing implementations?
                Kenneth Almquist

Volume-Number: Volume 11, Number 66

From jsq  Wed Jun 17 09:22:46 1987
Posted-Date: 17 Jun 87 14:22:34 GMT
Received-Date: Wed, 17 Jun 87 09:22:46 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA19662; Wed, 17 Jun 87 09:22:46 CDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: tar vs. cpio
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 17 Jun 87 14:22:34 GMT
Apparently-To: std-unix-archive

Yesterday was 16 June, which was the day I said I would collect
tar and cpio comments until.  Included below is the revised note
for P1003.1, incorporating those comments.  I will deliver it
to P1003.1 in Seattle Monday.



                                  tar vs. cpio      IEEE P1003.1 N.___
                                                          17 June 1987

                               John S. Quarterman

                    Institutional Representative from USENIX
                                   usenix!jsq



          Secretary, IEEE Standards Board
          Attention: P1003 Working Group
          345 East 47th St.
          New York, NY 10017

          In both the Trial Use Standard and the current Draft 10,
          POSIX sS10.1 describes a data interchange format based on the
          tar program.  That section has appeared in every draft of
          IEEE 1003.1 in some form and has always been based on tar
          format.  The P1003.1 Working Group has recently received two
          related proposals regarding that section: one to add cpio
          format (including old-style, non-ASCII (non c option)
          format); <N.048 Lorraine C. Kevra> <V11N14> <V11N25 Eric S.
          Raymond> the other to replace the existing tar-based format
          with cpio format.  <N.043 X/OPEN> <V11N13> Some
          clarifications were received to the former.  <N.064 Dominic
          Dunlop> <V11N15> It was also proposed verbally in the latest
          Working Group meeting to drop sS10.1 altogether and let
          P1003.2 handle the issue.  <V11N08> <V11N11> <V11N09 Guy
          Harris> <V11N12 Doug Gwyn>

          The present note is a response to those proposals.  Much of
          the detail in it is derived from articles posted in the
          USENET newsgroup comp.std.unix.  Those articles are
          referenced with this format: <V11N09 Guy Harris> which gives
          the volume (always 11) and number of the article, and the
          name of the submittor.  If no submittor name is given, the
          posting was by the moderator, John S. Quarterman.  Thanks to
          those who submitted articles.  However, the content of this
          note is solely the responsibility of the author.

          This note is addressed to P1003.1, and is concerned with
          data interchange formats.  Although user interface issues
          may be of interest to P1003.2, they are not addressed here.

          There are a number of problems with both cpio formats.
          First, those related to the non-ASCII format:

            1.  Numerous parameters, including inode numbers, mode
                bits, and user and group IDs, are kept in two-byte
                binary integers.  This has historically produced
                serious byte-order problems when data is moved among
                systems with different byte orders.  <V11N09 Guy
                Harris>








          Page 2                  tar vs. cpio      IEEE P1003.1 N.___



            2.  The byte-swapping and word-swapping options to the
                cpio program are inadequate patches; with an ASCII
                format the problem would not be present.  The options
                are not consistent across versions of the program: in
                System III, data blocks and file names are byte
                swapped; in System V, only data blocks are byte
                swapped.  <V11N09 Guy Harris> <V11N47 Andrew
                Tannenbaum>

            3.  The two-byte integer format limits the range of inode
                numbers to 0..65535.  Many current file systems are
                bigger than that.  <V11N37 Paul Eggert> <V11N39 Henry
                Spencer>

          Non-ASCII cpio format is clearly not portable and should not
          even be considered for standardization.  <V11N12 Doug Gwyn>

          There are several problems that occur even with the ASCII
          cpio format:

            1.  Many implementations of cpio only look at the lower 16
                (or even 15) bits of the inode number, even in ASCII
                format.  <V11N39 Henry Spencer> This is because the
                variable that is used to contain the value is declared
                to be unsigned short, just as in binary format.  Thus,
                even though ASCII cpio format only constrains this
                number to the range 0..262143, the format is still
                less than portable.  <V11N37 Paul Eggert>

            2.  The proposed cpio ASCII format as specified, <N.048
                Lorraine C. Kevra> <V11N14> is not portable because
                the proposal assumes that sizeof(int) == sizeof(long).
                <N.064 Dominic Dunlop> <V11N15>

            3.  The file type is written in a numerical format, making
                it UNIX specific rather than POSIX specific, since
                POSIX (and tar) specifies symbolic, rather than
                numerical, values for file types.  <V11N09 Guy Harris>

            4.  Hard links are not handled well, since cpio format
                does not directly record that two files are linked.
                If two files that are linked are written in cpio
                format, two copies will be written.  The cpio program
                detects duplicate files by matching pairs of (h_dev,
                h_ino) and producing links, but that is done after the
                fact.  <V11N09 Guy Harris> <V11N45 Guy Harris> <V11N54
                Ian Donaldson> (There is a program, afio, that handles
                cpio format more efficiently in this and other cases
                than the licensed versions of the program.) <V11N21
                Chuck Forsberg>








          Page 3                  tar vs. cpio      IEEE P1003.1 N.___



            5.  Symbolic links are not handled at all, and no type
                value is reserved for them.  This makes cpio useless
                on a large class of historical implementations (those
                based on 4.2BSD or its file system) for one of the
                main purposes of POSIX sS10.1: archiving files for
                later retrieval and use on the same system.  Although
                it is possible to extend cpio to handle symbolic
                links, and at least one vendor has done this, <V11N45
                Guy Harris> the format proposed to P1003.1 is the
                format in the SVID, and does not handle symbolic
                links.

            6.  The cpio format is less common than tar format: there
                are few historical implementations from Version 7 on
                that do not have tar; there are many that do not have
                cpio.  <V11N09 Guy Harris> <V11N10 Charles Hedrick>
                <V11N24 Jim Cottrell> It is true that cpio (non-ASCII
                format) was invented before tar, <V11N22 Joseph S. D.
                Yao> apparently in PWB System 1.0.  <V11N26 Joseph S.
                D. Yao> The cpio program was first available outside
                AT&T with PWB/UNIX 1.0, <V11N45 Guy Harris> <V11N63
                Joseph S. D. Yao> and later with System III.  However,
                in the interim, Version 7, which did not include cpio
                <V11N53 Bill Jones> <V11N62 Guy Harris> but did
                include tar, became the most influential system.
                There was a V7 addendum tape, but it also did not
                include cpio (according to its README file); <V11N65
                Rick Adams> the addendum tape was in tar format.
                Also, it appears that the cpio format of PWB was not
                the same as that of System III.  <V11N39 Henry
                Spencer> And System III and all releases of System V
                include tar.  <V11N26 Joseph S. D. Yao> <V11N63 Joseph
                S. D. Yao> <V11N45 Guy Harris> <V11N47 Andrew
                Tannenbaum>

            7.  It is very late in the process to propose that P1003.1
                adopt cpio format now, especially considering that it
                was originally proposed to and rejected by the
                /usr/group committee before P1003.1 was even formed.
                <V11N39 Henry Spencer>

          Advantages of cpio format include:

            1.  Both X/OPEN <N.043 X/OPEN> <V11N13> and the SVID
                <N.048 Lorraine C. Kevra> <V11N14> use it, although
                evidently defined somewhat differently.  <N.064
                Dominic Dunlop> <V11N15>

            2.  Archives made in cpio format are often smaller than
                ones in tar format.  <V11N44 Mark Horton> But this is
                only because of the headers, and thus the effect







          Page 4                  tar vs. cpio      IEEE P1003.1 N.___



                diminishes with larger files.

            3.  On a local (non-networked) system, cpio is more
                efficient at copying directory trees than tar.
                <V11N46 Steve Blasingame> However, this is really an
                implementation issue.

          There are several advantages to the current tar-based format
          as specified in sS10.1:

            1.  There are no byte- or word-swapping issues caused by
                the format, since all the header values are ASCII byte
                streams.  <V11N17 John Gilmore>

            2.  There are no inode numbers recorded, and file types
                are kept in symbolic form, so the format is less
                implementation-specific than cpio format.  <V11N17
                John Gilmore>

            3.  Historical tar format is the most widely used, as
                discussed in 6. above, despite apparent assertions to
                the contrary.  <N.043 X/OPEN> <V11N13>

            4.  The format specified in sS10.1 is upward-compatible
                with tar format.  Old tar archives can be extracted by
                a program that implements sS10.1.  Archives using some
                of the extensions of sS10.1 can be extracted with old
                (Version 7) tar programs, although symbolic links will
                not be extracted and contiguous files will not be
                handled properly (cpio does not handle these
                capabilities at all).  Files with very long names will
                not be handled properly (cpio does no better at this).
                All tar implementations are compatible to this extent.
                <V11N17 John Gilmore>

            5.  The /usr/group working group and P1003.1 have already
                done the work <P.061> <M.019 5.1.121 Pg.13> <RFC.003
                #121> <P.038> <P.006> required to add optional
                extensions (such as symbolic links, long file names,
                <V11N49 Jerry Schwarz> <V11N50 Michael MacDonald> and
                contiguous files) that are needed on many historical
                implementations and that cpio format lacks.

            6.  The format is extensible for future facilities.
                <V11N39 Henry Spencer>

            7.  There is a public domain implementation of the format
                of sS10.1.  That implementation provided feedback which
                led to improvements in the current specification, and
                has been in use for years in transferring data with
                licensed tar implementations.  <V11N17 John Gilmore>







          Page 5                  tar vs. cpio      IEEE P1003.1 N.___



            8.  Many people prefer the user interface of the cpio
                program to that of the tar program, because the former
                can accept a list of pathnames to archive on standard
                input while the latter takes them as arguments,
                limiting the length of the list.  <V11N34 Andrew
                Tannenbaum> However, the above-mentioned public domain
                implementation of tar accepts pathnames on standard
                input, <V11N17 John Gilmore> <V11N19 Jim Cottrell> and
                at least one vendor sells a version of tar that can do
                this.  <V11N48 Michael Gersten> Diffs to standard tar
                to add an option to accept pathnames on standard input
                when creating an archive have also been posted to
                USENET.  <V11N36 John Gilmore> The user interface is,
                in any case, irrelevant to P1003.1.  <V11N39 Henry
                Spencer> <V11N40 Rahul Dhesi>

          Disadvantages of tar format:

            1.  If an attempt is made to extract only the second of a
                pair of hard linked files the tar program will attempt
                to link the second file to the nonexistent first file,
                and nothing will be extracted.  Although a
                sufficiently clever implementation could avoid this,
                the problem can be considered to be in the archive
                format.  <V11N66 Kenneth Almquist>

          There are some problems that neither tar nor cpio handles
          well.

            1.  File names still longer than the length of PATH_MAX
                (at least 255) <V11N50 Michael MacDonald> that the
                POSIX format allows (and than the 128 that cpio
                permits or than the 100 that historical tar allows)
                would be preferable, although the POSIX limit is
                useful for most cases.  <V11N54 Ian Donaldson>

            2.  An option to prevent crossing mount points would be
                useful for backups.  <V11N19 Jim Cottrell> <V11N22
                Joseph S. D. Yao> However, this appears to be more of
                an implementation issue than a format issue, <V11N28
                Dave Brower> <V11N32 Joseph S. D. Yao> especially
                considering that there are options to find in 4.2BSD,
                <V11N24 Jim Cottrell> SunOS 3.2, <V11N36 John Gilmore>
                and System V Release 3.0 <V11N35 Mike Akre> that take
                care of this.

            3.  The default block size in many tar implementations is
                too large for some tape controllers to read <V11N27
                Rob Lake> (the 3B20 has this problem).  This is not a
                problem with the interchange format, however.








          Page 6                  tar vs. cpio      IEEE P1003.1 N.___



          There is nothing that the proposed cpio can handle that the
          tar-based format already in POSIX sS10.1 cannot handle; in
          fact, the former is less capable.  If cpio format were
          augmented to handle missing capabilities, it would be
          subject to the same objections now aimed at the format given
          in sS10.1: that it was not identical with an existing format.

          There is no advantage in replacing the current tar-based
          format of sS10.1 with cpio format.  There is also no
          advantage in adding cpio format, because two standards are
          not as good as a single standard.

          Some have recommended removing sS10.1 from POSIX altogether,
          <V11N12 Doug Gwyn> perhaps with a recommendation for P1003.2
          to pick up the idea.  <V11N09 Guy Harris> While I believe
          that that would be preferable to adding cpio format, whether
          or not tar format remains, I recommend leaving sS10.1 as it
          is, because

             o+ The inclusion of an archive/interchange file format is
               in agreement with the purpose of POSIX to promote
               portability of application programs across interface
               implementations.  Some format will be used.  It is to
               the advantage of the users of the standard for there to
               be a standard format.

             o+ The de facto standard is tar format.  The current sS10.1
               standardizes that, and provides upward-compatible
               extensions in areas that were previously lacking.

          The Archive/Interchange File Format should be left as it is.

                                                  Thank you,



                                                  John S. Quarterman


Volume-Number: Volume 11, Number 67

From jsq  Wed Jun 17 09:35:48 1987
Posted-Date: 16 Jun 87 19:53:13 GMT
Received-Date: Wed, 17 Jun 87 09:35:48 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA19862; Wed, 17 Jun 87 09:35:48 CDT
From: John R. Levine <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: UNIX Facilities for Interpreters
Summary: file mapping is a reasonable idea, do it right.
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: ima![e-mail] (John R. Levine)
Organization: Javelin Software Corporation
Date: 16 Jun 87 19:53:13 GMT
Apparently-To: std-unix-archive

From: [e-mail] (John R. Levine)

In article <[e-mail]> [e-mail] (Bob Alexander) writes:
>[interpretive languages would work better if they could page their data
>memory like compiled languages do, so how about a vread() call that maps
>instead of reading?]

When we were designing AIX, the Sys V port for the RT PC, the same question
of file mapping came up, this time in the context of doing data base work.
The original proposal was for something like the vread() call, but we
eventually decided on, essentially:

    pointer = filemap(fd);

where fd is an open file descriptor.  It maps the entire file into the
address space, somewhere, and gives you a pointer to it.  It fails if there
isn't enough address space.  This had the advantage over the vread() approach
that it generalizes better for file writing -- if the file is mapped
read/write, anything you write to the segment goes into the file, adding
new blocks into the file if need be.  If you don't want the file's size to be a
multiple of a page, use ftruncate() to set its length.

Notice that vread() can easily be simulated by this scheme, but not vice
versa.  I agree that this scheme fails dismally if you don't actually have
paged memory, but I'd rather have this as the underlying call and vread() as
a library routine that maps on systems where it can and reads on systems
where it can't.

John Levine, ima!johnl or [e-mail]
---
John R. Levine, Javelin Software Corp., Cambridge MA [phone]
{ ihnp4 | decvax | cbosgd | harvard | yale }!ima!johnl, [e-mail]
U.S. out of New Mexico!

Volume-Number: Volume 11, Number 68

From jsq  Fri Jun 19 10:21:17 1987
Posted-Date: 17 Jun 87 20:30:39 GMT
Received-Date: Fri, 19 Jun 87 10:21:17 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA09127; Fri, 19 Jun 87 10:21:17 CDT
From: Henry Spencer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Henry Spencer)
Date: 17 Jun 87 20:30:39 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Henry Spencer)

> >        1)  Data is not block oriented. This slows down processing...
> I miss this one. It may slow things under MVS, but there's no reason
> why reading less physical data should slow things down. Quite the
> opposite.

The problem being alluded to is that the data is not block-aligned.  This
is a bit of a performance pain when the disks are block-aligned, although
tar's block alignment isn't going to help a lot if the disk blocks are bigger
than tar's (which they normally are, nowadays).

> >        2)  There is no room left in the header. No customization
> >            possible (without also sending the customized program).
> This is a major advantage. Save us from "custom standard' format. The
> custom stuff belongs in the *file*, not the format (in my opinion).

The point here is that you can customize tar to some degree *without*
making it incompatible with the standard ones.  (We did, for example.)
This is not true of cpio, since there's no spare space in the header.

                Henry Spencer @ U of Toronto Zoology
                {allegra,ihnp4,decvax,pyramid}!utzoo!henry

Volume-Number: Volume 11, Number 69

From jsq  Fri Jun 19 10:26:33 1987
Posted-Date: 17 Jun 87 20:30:43 GMT
Received-Date: Fri, 19 Jun 87 10:26:33 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA09283; Fri, 19 Jun 87 10:26:33 CDT
From: Henry Spencer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: <limits.h> - copy of item posted to comp.unix.wizards
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Henry Spencer)
Date: 17 Jun 87 20:30:43 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Henry Spencer)

> Agreed that finding out how many files you have to close in order to be
> sure you've closed them all is a pain on most implementations of UN*X.
> IEEE 1003.1 is attempting to address this...

Actually, one way to solve this *particular* problem without the nastiness
of the general case would be to have close() yield EBADF (as it does now)
for a legal-but-not-open descriptor number and EDOM for a descriptor number
beyond the implementation's limit.  (1003 doesn't currently include EDOM in
its error-number list, since in existing implementations it's not returned
by the kernel, but adding it shouldn't hurt anything.)

Another alternative would be to vary the code based on whether there is a
higher-numbered descriptor still open or not.  It's no problem for the kernel
to keep track of the highest open descriptor, so that the decision can be
made quickly even on a system that allows lots of descriptors.

                Henry Spencer @ U of Toronto Zoology
                {allegra,ihnp4,decvax,pyramid}!utzoo!henry

Volume-Number: Volume 11, Number 70

From jsq  Fri Jun 19 10:34:08 1987
Posted-Date: 18 Jun 87 06:21:11 GMT
Received-Date: Fri, 19 Jun 87 10:34:08 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA09487; Fri, 19 Jun 87 10:34:08 CDT
From: Ian Donaldson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Ian Donaldson)
Organization: RMIT Comm & Elec Eng, Melbourne, Australia.
Date: 18 Jun 87 06:21:11 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Ian Donaldson)

In article <[e-mail]>, [e-mail] (Moderator, John Quarterman) writes:
>
> [ We are discussing standardizing a data interchange/archive format
> in a standard that its authors explicitly wanted to be implementable
> on hosted, i.e., non-UNIX-based, systems.  The inclusion of inode
> numbers is a problem for such implementations, especially when it
> is not necessary, as demonstrated by the tar format.  -mod ]

How much of a problem?  Surely the numerical value of these numbers are
unimportant, but their relationship to other files in the same
archive is important.  They are just magic cookies specifying whether
file A is the same as file B.  Any computer can generate such
magic cookies.

For so-called implimentations of "UNIX" (as opposed to UN*X)
that don't have linked file capabilities (gasp!) this is still not a problem,
as archives that they generate won't have linked files, and archives
that they read will simply ignore this information.

Same goes for tar.

Ian D.

Volume-Number: Volume 11, Number 71

From jsq  Fri Jun 19 10:39:04 1987
Posted-Date: 19 Jun 87 03:15:09 GMT
Received-Date: Fri, 19 Jun 87 10:39:04 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA09587; Fri, 19 Jun 87 10:39:04 CDT
From: Michael Gersten <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: UNIX Facilities for Interpreters
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Michael Gersten)
Organization: Ucla Computer Club (disclaimer)
Date: 19 Jun 87 03:15:09 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Michael Gersten)

vread() is a nice idea, but fairly (very) limited. In particular, it requires
that the p-code being interpreted be stored on the disk in semi-compiled
form, and used as pure.

May I remind you that INTERACTIVE interpreters (which is the whole point
of interpreters) do not do this; most BASIC's tokenize the text as they
read it in, so it is not pure; any decent interactive system will have
dificulty utilizing this because they do not p-compile first.

            Michael Gersten

Volume-Number: Volume 11, Number 72

From jsq  Fri Jun 19 10:44:26 1987
Posted-Date: 19 Jun 87 01:09:02 GMT
Received-Date: Fri, 19 Jun 87 10:44:26 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA09712; Fri, 19 Jun 87 10:44:26 CDT
From: Skip Montanaro <[e-mail]>
Newsgroups: comp.std.unix
Subject: Replacement for signals in POSIX?
Summary: Is there any such beast?
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Skip Montanaro)
Organization: General Electric CRD, Schenectady, NY
Date: 19 Jun 87 01:09:02 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Skip Montanaro)

Perhaps this has been discussed before, but I've only recently begun
reading this group.

At the recent USENIX conference in Phoenix the issue of signal
handling came up in relation to the MACH kernel. It seems that signals
and threads (or lightweight processes, if you will) don't fit together
very well. If you think about it for a bit, it's hard to decide which
thread should catch a signal: the active thread? the one that set the
signal? some designated signal catcher? The MACH types have hacked
something together. (I think they decided the active thread would
catch it, but don't quote me.)

My question is, has the POSIX group discussed any alternatives to the
signal facility?

Mail me your replies. I'll summarize if there's any interest.

         Skip|  ARPA:      [e-mail]
    Montanaro|  UUCP:      [e-mail]
[phone]|  GE DECnet: advax::"[e-mail]"

Volume-Number: Volume 11, Number 73

From jsq  Fri Jun 19 10:49:51 1987
Posted-Date: 18 Jun 87 16:12:39 GMT
Received-Date: Fri, 19 Jun 87 10:49:51 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA09852; Fri, 19 Jun 87 10:49:51 CDT
From: Simon Brown <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: open file range
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Simon Brown)
Organization: Computer Science Department, Edinburgh University
Date: 18 Jun 87 16:12:39 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Simon Brown)

In article <[e-mail]> Doug Gwyn (VLD/VMB) <[e-mail]> writes:
>From: Doug Gwyn (VLD/VMB) <[e-mail]>
>
>I submitted a proposal to X3J11 that fflush((FILE*)NULL) would
>flush ALL output buffers, since there is no other good way to
>accomplish that.  It seems that close(-1) might be a similar
>solution for POSIX.  (Since nobody is supposed to be doing this
>currently, it is available for assigning new semantics to.)
>

Arghhh, no! Don't do that! Ok, it might seem a truly wonderful idea, but
it would mean that things like
    fd = open(some-random-filename,something);
    do-something-bizarre-with-fd;
    close(fd);
will do a "close(-1)" if the open happened to fail for some reason or other,
which is harmless at the moment (just returns -1, errno=EBADF), but would be
a bit tragic with this new semantics!
Yes, I know this isn't a problem if everyone always checks the return-value
from open(), creat(), etc..., but lots of programs aren't that pessimistic!

--
----------------------------------
| Simon Brown                  | UUCP:  seismo!mcvax!ukc!{its63b,cstvax}!simon
| Department of Computer Science | JANET: [e-mail].{its63b,cstvax}
| University of Edinburgh,       | ARPA:  simon%{its63b,cstvax}.ed.ac.uk ...
| Scotland, UK.             |                @cs.ucl.ac.uk
----------------------------------     "Life's like that, you know"

Volume-Number: Volume 11, Number 74

From jsq  Mon Jun 29 13:26:14 1987
Posted-Date: 20 Jun 87 19:45:02 GMT
Received-Date: Mon, 29 Jun 87 13:26:14 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA11163; Mon, 29 Jun 87 13:26:14 CDT
From: Guy Harris <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: open file range
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Guy Harris)
Date: 20 Jun 87 19:45:02 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Guy Harris)

> ...it would mean that things like
>     fd = open(some-random-filename,something);
>     do-something-bizarre-with-fd;
>     close(fd);
> will do a "close(-1)" if the open happened to fail for some reason or other,
> which is harmless at the moment (just returns -1, errno=EBADF), but would be
> a bit tragic with this new semantics!
> Yes, I know this isn't a problem if everyone always checks the return-value
> from open(), creat(), etc..., but lots of programs aren't that pessimistic!

Programs that are not that pessimistic are broken.  I see no reason
to reject this proposal out of hand merely because it would expose
bugs in programs such as these; indeed, the fact that it exposes
these bugs might be an excellent reason to do it - it is very
aggravating to deal with programs that exhibit this sort of unwarranted
optimism, as they do not give very good error indications when this
optimism is unwarranted (if they bother giving one at all!).


Volume-Number: Volume 11, Number 75

From jsq  Mon Jun 29 13:34:17 1987
Posted-Date: 29 Jun 87 18:34:03 GMT
Received-Date: Mon, 29 Jun 87 13:34:17 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA11371; Mon, 29 Jun 87 13:34:17 CDT
From: (Michael <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Michael)
Organization: STB BBS, La, Ca, USA, 90402, [phone]
Date: 29 Jun 87 18:34:03 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Michael)

Actually, Tar CAN handle links properly, with the present file format.

There are two types of input to tar (generally): Regular files, which can
be seek'd to the proper place, and special files which cannot be seek'd.
They can, however, be close(); open() 'd, which does a rewind on any device
that I'm familiar with.
Presto, you've just seeked to the beginning, now you can skip as much as you
need to get to the file.

The only thing this won't work with is pipes; the only thing I can think
of using pipes with tar are copying directories (in which case selective
retrieval isn't needed) and compressed archives (you're out of luck).
--
: Michael Gersten        seismo!scgvaxd!stb!michael
: Ground floor, comming up -- 1-3-7

Volume-Number: Volume 11, Number 76

From jsq  Mon Jun 29 13:44:23 1987
Posted-Date: 21 Jun 87 21:41:40 GMT
Received-Date: Mon, 29 Jun 87 13:44:23 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA11623; Mon, 29 Jun 87 13:44:23 CDT
From: Cameron Simpson <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Message-Id: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Cameron Simpson)
Date: 21 Jun 87 21:41:40 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Cameron Simpson)

>From: [e-mail] (Kenneth Almquist)
>Subject: Re: tar vs. cpio
>Message-ID: <[e-mail]>
>
>[ example of failure of tar's format ]
>
>So it seems to me that tar cannot be made to handle links correctly
>unless the tar archive format is changed.  The cpio format, on the other
>hand, allows links to be handled correctly.  The fact that cpio includes
>inode numbers is not all that major a problem for non-UNIX based systems.
>Since the only thing the inode numbers are used for is resolving links,
>a system which does not support (non-symbolic) links can leave garbage
>in the inode field when writing tapes.  A system which does have links
>but does not have inode numbers can use a sequence number in place of
>the inode number.

Please, monotonic garbage! Imagine extracting such a tape on a system
which *does* support (non-symbolic) links. I can easily envisage an
implementation which simply did not initialise the garbage, and wrote
said garbage the same for each file. On extraction you'd end up with a
single file with LOTS of links!-)
    - Cameron Simpson

ACSnet:    [e-mail]    JANET: elecvax.eecs.unsw.oz!cameron@ukc
CSNET:    [e-mail]        BITNET:    cameron%elecvax.oz@CSNET-RELAY
ARPA:    [e-mail]
UUCP:    ...!seismo!munnari!elecvax.eecs.unsw.oz!cameron
     or    munnari!elecvax.eecs.unsw.oz![e-mail]


Volume-Number: Volume 11, Number 77

From jsq  Mon Jun 29 13:50:30 1987
Posted-Date: 23 Jun 87 18:32:18 GMT
Received-Date: Mon, 29 Jun 87 13:50:30 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA11717; Mon, 29 Jun 87 13:50:30 CDT
From: Marc W. Mengel <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Reply-To: moss!cuuxb![e-mail] (Marc W. Mengel)
Organization: AT&T-DSD, Software Support, Lisle IL
Date: 23 Jun 87 18:32:18 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Marc W. Mengel)

In article <[e-mail]> [e-mail] (Kenneth Almquist) writes:
:Several people have suggested that tar's method of handling links is
:better than cpio's.  After looking at the tar format, I wondered how
:tar could possibly handle links correctly.   A quick experiment showed
:that it doesn't.  Try the following:
:
:    > file1
:    ln file1 file2
:    tar -cf archive file1 file2
:    rm file1 file2
:    tar -xf archive file2
:
:The second tar command will fail because tar will simply try to create
:a link from file1 to file2, but since I only requested that file2 be
:extracted file1 does not exist.
:
:I claim that this is a bug in the tar archive format rather than just
:the tar program.  Consider what tar must do to function correctly.  Tar
:could remember the location of file1 and lseek to it in this particular
:example, but in general the input to tar is not a regular file and thus
:may not be seekable.
:                Kenneth Almquist

Actually this is easily solved using the current format, you need merely
ensure that when a file has multiple links, that the file's data is put
on the archive only the last time that it is referenced.  This guarantees
that the location of file1 in your example is always further along the
archive than file2, and therefore no "rewinding" is ever needed to find
the file after discovering that a link to it has been requested.  This
does require the program to make two traversals over the directory tree
( 1 to determine where the last reference to each file in the subtree
occurs, 1 to actually write out the files), but the format itself is *not*
inherently broken.

--
 Marc Mengel
 ...!{moss|lll-crg|mtune|ihnp4}!cuuxb!mwm

Volume-Number: Volume 11, Number 78

From jsq  Mon Jun 29 13:58:39 1987
Posted-Date: 24 Jun 87 00:56:16 GMT
Received-Date: Mon, 29 Jun 87 13:58:39 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA11891; Mon, 29 Jun 87 13:58:39 CDT
From: Henry Spencer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Summary: Cpio format makes correct handling of links impossible, too.
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Henry Spencer)
Date: 24 Jun 87 00:56:16 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Henry Spencer)

As a counterpoint to Kenneth Almquist's example of tar fouling up links,
try the following:

    echo hi >one
    ln one two
    ls one two | cpio -o >/tmp/foo
    rm one two
    cpio -i one </tmp/foo
    cpio -i two </tmp/foo

Now we have cpio creating two files where there was supposed to be only one
with two links.  Note that tar would get this one right!  (Although you would
have to be careful to get the order right, admittedly a wart.)

The moral of the story is that it is very hard to handle links properly in
a format like tar or cpio, and *neither* of the existing formats is bullet-
proof in the presence of links.  This is not a valid argument for or against
either format; they merely screw up in different ways.  One can argue about
the relative probabilities of the different screwup types causing trouble,
but I think the point is made.

                Henry Spencer @ U of Toronto Zoology
                {allegra,ihnp4,decvax,pyramid}!utzoo!henry

Volume-Number: Volume 11, Number 79

From jsq  Mon Jun 29 14:06:49 1987
Posted-Date: 24 Jun 87 00:56:19 GMT
Received-Date: Mon, 29 Jun 87 14:06:49 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA12145; Mon, 29 Jun 87 14:06:49 CDT
From: Henry Spencer <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]>, <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Henry Spencer)
Date: 24 Jun 87 00:56:19 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Henry Spencer)

> ... A system which does have links
> but does not have inode numbers can use a sequence number in place of
> the inode number.

Suppose it wants to use a sequence number that is bigger than 16/18 (16
for binary cpio format, 18 for ASCII cpio format) bits?  For that matter,
what if *inode* numbers are bigger than that?  This argument would be a
whole lot stronger if the cpio formats (note plural) left more room for
this particular magic cookie.

> I wonder if there is still any chance of a new interchange format that
> corrected the deficiencies of both cpio and tar being accepted as the
> standard...

Not unless there were truly overwhelming technical reasons for picking it.
Even the cpio formats, scummy though they are, are readily readable without
new software at a great many existing sites.  The same is true of tar on an
even larger scale.  A new format would start from zero... not an attractive
proposition.  I would also observe that we don't *want* the sort of format
that a standards committee would invent -- have you studied, say, X.400
lately?  Better to pick the best of existing practice and standardize that,
possibly with minor changes.  That is what standards committees are really
supposed to do.

                Henry Spencer @ U of Toronto Zoology
                {allegra,ihnp4,decvax,pyramid}!utzoo!henry

Volume-Number: Volume 11, Number 80

From jsq  Mon Jun 29 14:14:16 1987
Posted-Date: 24 Jun 87 22:50:26 GMT
Received-Date: Mon, 29 Jun 87 14:14:16 CDT
Received: by sally.utexas.edu (5.54/5.51)
    id AA12355; Mon, 29 Jun 87 14:14:16 CDT
From: Andrew Klossner <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: Replacement for signals in POSIX?
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Andrew Klossner)
Organization: Tektronix, Wilsonville, Oregon
Date: 24 Jun 87 22:50:26 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Andrew Klossner)

    "My question is, has the POSIX group discussed any alternatives
    to the signal facility?"

The answer is no.  The charter of a standards group is to codify
existing practice, not to invent something new.  All too often this
charter is violated, to the detriment of the community.

[ Unfortunately, it's not always easy to stay on one side of the line.
The signal facilities in POSIX at the moment are not quite like those
in any existing system, i.e., they are to some extent an invention.
This was necessary in order to produce something that was implementable
in the context of the various existing systems.  -mod ]

  -=- Andrew Klossner   (decvax!tektronix!tekecs!andrew)       [UUCP]
                        ([e-mail])   [ARPA]

Volume-Number: Volume 11, Number 81

From root  Tue Jun 30 22:49:54 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA05749; Tue, 30 Jun 87 22:49:54 EDT
From: Jim McGinness <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX Portability Workshop
Keywords: POSIX, USENIX, Portability
Message-Id: <[e-mail]>
Sender: ut-sally!std-unix
Reply-To: [e-mail] (Jim McGinness)
Date: 1 Jul 87 01:10:34 GMT
Apparently-To: std-unix-archive


                         Call for Papers
                   POSIX Portability Workshop
                    Berkeley Marina Marriott
                       October 15-16, 1987

This USENIX workshop will bring together system  and  application
implementors  faced  with  the  problems, "challenges," and other
considerations that arise from attempting to make their  products
compliant  with  IEEE Std 1003.1.  The first day of the  workshop
will consist of presentations of brief position papers describing
experiences,  dilemmas,  and  solutions.  On the second day it is
planned to form smaller focus  groups  to  brainstorm  additional
solutions,  dig  deeper into specific areas, and attempt to forge
common approaches to some of the dilemmas.  Suggestions for topic
areas and position papers include:

C Language Issues               Internationalization
Networked/Distributed Implementations   Pipes and FIFOs
Timer resolution, ranges        Signals
Conformance verification        Security concerns
Job control, process groups     Limits: documentation and inquiry
Implications for user interfaces Implications for commands

Position papers must be submitted by August 15, 1987 to:

                          Jim McGinness
                  Digital Equipment Corporation
                Continental Boulevard MK02-1/HIO
                       Merrimack, NH 03054
                         [phone]
                           decvax!jmcg
                       [e-mail]

For registration or hotel information, contact:
Judith F. DesHarnais
USENIX Conference Coordinator
PO Box 385
Sunset Beach, CA 90742
[phone]
usenix!judy

Volume-Number: Volume 11, Number 82

From jsq  Thu Jul  2 00:01:15 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA05723; Thu, 2 Jul 87 00:01:15 EDT
From: Andrew Klossner <[e-mail]>
Newsgroups: comp.std.unix
Subject: Killing programs that close(-1)
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: [e-mail] (Andrew Klossner)
Organization: Tektronix, Wilsonville, Oregon
Date: 30 Jun 87 14:58:36 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Andrew Klossner)

[With regard to programs that inadvertantly do close(-1):]

    "Programs that are not that pessimistic are broken.  I see no
    reason to reject this proposal out of hand merely because it
    would expose bugs in programs such as these ..."

One of the major goals of a standardization effort is to "do no harm":
not to invalidate facilities which are commonly available and upon
which many programs may depend (even if such dependence is
inadvertant).  The requested facility, to close all open files, could
just as easily be implemented with a new function, e.g., "closeall()".
There is no reason to go out of our way to overload an existing
function, one whose semantics have been fixed for over a decade.

A much more extreme example of this philosophy appears when Unix
vendors go out of their way to place zeros at location 0, so that
programs developed on VAXes which "expect" to find 0 when dereferencing
a 0 pointer will work.  No, I'm not suggesting that POSIX or X3J11
mandate this, but vendors such as my employer do this for marketability
reasons.  Imagine that a potential customer has one of my workstations
and one of yours; on yours their VAX application compiles and runs just
fine, while on mine it crashes with "bus error".  No amount of my
explaining that their program shouldn't dereference a null pointer is
going to get me the sale unless my machine stands out in other ways.

  -=- Andrew Klossner   (decvax!tektronix!tekecs!andrew)       [UUCP]
                        ([e-mail])   [ARPA]

Volume-Number: Volume 11, Number 83

From root  Thu Jul  2 21:25:20 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA04028; Thu, 2 Jul 87 21:25:20 EDT
From: Doug Gwyn  <[e-mail]>
Newsgroups: comp.std.unix
Subject: Re: UNIX Facilities for Interpreters
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]>
Sender: ut-sally!std-unix
Reply-To: [e-mail] (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Date: 19 Jun 87 01:26:25 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Doug Gwyn )

In article <[e-mail]> ima![e-mail] (John R. Levine) writes:
>    pointer = filemap(fd);

Hey, I really like this.  I can even see how to implement it on a mickey-mouse
(non-paged) architecture, and how to fake the facility (always return NULL).
This is a whole lot better than vread() and kin.

Volume-Number: Volume 11, Number 84

From root  Thu Jul  2 21:32:27 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA04054; Thu, 2 Jul 87 21:32:27 EDT
From: Chuck Howell <[e-mail]>
Newsgroups: comp.std.unix
Subject: Widely used tools on various hosts
Message-Id: <[e-mail]>
Sender: ut-sally!std-unix
Reply-To: [e-mail]
Date: 1 Jul 87 15:38:49 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Chuck Howell)
To: [e-mail], [e-mail], [e-mail],
        [e-mail], [e-mail],
        [e-mail], [e-mail],
        [e-mail], [e-mail],
        [e-mail], [e-mail],
        [e-mail], [e-mail]

I am interested in information on widely used tools that are
available on a variety of hosts.  For example, EMACS-based editors
are available for a wide range of UNIX hosts, for micros running
MS/DOS, and I believe for VAX VMS.  Scribe is also available for
several different operating systems.  What other machines/OSes does
Scribe or EMACS run on?  What are other examples of tools that run on
various operating systems?  I imagine there are a number of examples
from the microcomputer world (e.g. Lotus on a variety of OSes).
I'm interested in a wide definition of "tools"; for example, I
would consider the availability of TCP/IP on UNIX and VMS, or the
availability of NFS on UNIX and PCs, to be good examples.

Please send to me; I'm not on all of the lists I've mailed to.
I'll summarize all responses received by 10 July and redistribute
to all mailing lists.

Thanks,

Chuck Howell
ARPA: [e-mail] or
    [e-mail]

Volume-Number: Volume 11, Number 85

From root  Fri Jul  3 22:13:55 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA13578; Fri, 3 Jul 87 22:13:55 EDT
From: David Zink <bunker![e-mail]>
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Message-Id: <[e-mail]>
References: <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: ut-sally!std-unix
Reply-To: harvard!husc6!bunker![e-mail] (David Zink)
Organization: Bunker Ramo an Olivetti Company, Shelton CT
Date: 3 Jul 87 21:00:04 GMT
Apparently-To: std-unix-archive

From: harvard!husc6!bunker![e-mail] (David Zink)

In article <[e-mail]> [e-mail] (Henry Spencer) writes:
)From: [e-mail] (Henry Spencer)
)
)As a counterpoint to Kenneth Almquist's example of tar fouling up links,
)try the following:
)
)    echo hi >one
)    ln one two
)    ls one two | cpio -o >/tmp/foo
)    rm one two
)    cpio -i one </tmp/foo
)    cpio -i two </tmp/foo
)
)Now we have cpio creating two files where there was supposed to be only one
)with two links.  Note that tar would get this one right!  (Although you would
)have to be careful to get the order right, admittedly a wart.)

Actually This should always create TWO FILES! Unless you want to go to
the effort of proving that one has not been modified when two is removed.
We're seeing two separate invocations of cpio with no knowledge of each
other -- How could it be correct to link them ??
:g/^>/s//;-)/

[ Um, haven't we about beat this subsubject to death?  - mod ]

Volume-Number: Volume 11, Number 86

From root  Fri Jul  3 22:16:41 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA13732; Fri, 3 Jul 87 22:16:41 EDT
From: Dominic Dunlop <[e-mail]@sphinx.co.uk>
Newsgroups: comp.std.unix
Subject: Re: a new? topic - dynamic loading
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: ut-sally!std-unix
Reply-To: [e-mail]@sphinx.co.uk (Dominic Dunlop)
Organization: Sphinx Ltd., Maidenhead, England
Date: 1 Jul 87 19:28:46 GMT
Apparently-To: std-unix-archive

From: mcvax!sphinx.co.uk![e-mail] (Dominic Dunlop)

Nice to see SAS on the net -- although your sales people play coy about if
and when a UNIX implementation might see the light of day  (no, I'm not
asking you to comment...)

In article <[e-mail]> you write:
>Is there any effort in the standards efforts to provide kernel (or CRT lib.)
>support for this [dynamic loading/execution from data space]?

No.  To my knowledge it hasn't come up at all on POSIX (although I didn't
attend last week's meeting in Seattle).  Not least of the problems is that

 1.  The classic BSD implemenataion depends on a highly machine-dependent
     aspect of VAX memory management.

 2.  Quite a few people (and I'd probably number myself among them)
     consider this aspect of VAX memory management to be brain-damaged, or
     at least to be something which could be done better by throwing a few
     more gates at the problem (gates weren't so cheap or fast in 1978).

 3.  Later memory management implementations may well specifically
     exclude ``doing things the VAX way'' because it is judged to be
     unclean and/or unsafe.  Certainly, many 68x00 implementations don't
     allow execution out of data space, and don't provide a kernel call
     which (in effect) allows programs to move the boundary between text
     and data.

Consequently, any attempt to introduce the topic to POSIX would be
controversial, and POSIX does not need controversy if a standard is to be
ratified on schedule!

To put it another way, this is a political issue...  However, if you were
to make a more or less formal proposal by mailing John Quarterman,
moderator of comp.std.unix (std-unix@ut-sally) you could flag a valid
technical issue as open, and might even get a formal reply from the working
group.

If you want to rope in somebody with heavy-duty experience of this issue,
Catalytix Corp. of Cambridge MA (phone [phone] -- I don't have a net
address) have had to fight it in bringing up their Safe-C interpreter in
a variety of UN*X and other environments.  (Safe-C is worth checking out
if you're a developer, anyway.)

The usual disclaimer: I don't speak for IEEE working group 1003.1 -- almost
nobody can (in fact, the IEEE carries professional liability insurance
just in case anybody wants to brief their lawyer to argue about it).  These
opinions are strictly my own.

[ The quickest way to make a proposal to IEEE P1003.1 (the POSIX committee)
is to mail a paper copy to

    Secretary, IEEE Standards Board
    Attention: P1003 Working Group
    345 East 47th St.
    New York, NY 10017

Formal notes to the committee have to go there, anyway, or be carried to
a Working Group meeting.  Feel free to submit a copy to comp.std.unix
if you want to.

As decided at the Seattle meeting (22-26 June 1987),
all proposed changes to the P1003.1 draft standard must be
in the form of balloting objections, i.e., actual proposed
wording for the standard with attached rationale is required.

You can still send in general comments, though.  Also, your note
might get redirected to another subcommittee which is more
directly addressing related issues.  Offhand, I don't know
which one that might be: perhaps one of the /usr/group
Technical Committees.

I play several roles related to POSIX, and they frequently get confused:
a) Moderator of comp.std.unix.
b) Institutional Representative from USENIX to IEEE P1003.
c) Member of the USENIX Board of Directors.
d) Private contractor for the P1003.1 Rationale, funded by /usr/group.

a) is largely a result of b), and c) is useful in doing b).
d) is completely unrelated to the other three, and is finished.

I can and sometimes do submit notes to P1003 as the USENIX
Institutional Representative (e.g., the tar vs. cpio note).
It's one of my functions in that role to gather information
from the USENIX membership and the public and also to distribute
information about POSIX and other standards.  So, I could submit
a note for you.  It will just get there faster if you do it yourself....

Dominic's disclaimer about speaking for IEEE or P1003 also
applies to me, of course.

-mod ]

Dominic Dunlop, Sphinx Ltd.    UKnet:    [e-mail]

Volume-Number: Volume 11, Number 87

From usenet  Wed Jul  8 11:48:38 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA00504; Wed, 8 Jul 87 11:48:38 EDT
From: Jim McGinness <[e-mail]>
Newsgroups: comp.std.unix
Subject: POSIX Portability Workshop
Keywords: POSIX, USENIX, Portability
Message-Id: <[e-mail]>
Sender: ut-sally!std-unix
Reply-To: [e-mail] (Jim McGinness)
Date: 1 Jul 87 01:10:34 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Jim McGinness)

[ The dates were wrong, due to an error on my part.  -mod ]

                         Call for Papers
                   POSIX Portability Workshop
                    Berkeley Marina Marriott
                       October 22-23, 1987

This USENIX workshop will bring together system  and  application
implementors  faced  with  the  problems, "challenges," and other
considerations that arise from attempting to make their  products
compliant with IEEE Standard 1003.  The first day of the workshop
will consist of presentations of brief position papers describing
experiences,  dilemmas,  and  solutions.  On the second day it is
planned to form smaller focus  groups  to  brainstorm  additional
solutions,  dig  deeper into specific areas, and attempt to forge
common approaches to some of the dilemmas.  Suggestions for topic
areas and position papers include:

C Language Issues                       Internationalization
Networked/Distributed Implementations   Pipes and FIFOs
Timer resolution, ranges                Signals
Conformance verification                Security concerns
Job control, process groups             Limits: documentation and inquiry
Implications for user interfaces        Implications for commands

Position papers must be submitted by August 15, 1987 to:

                          Jim McGinness
                  Digital Equipment Corporation
                Continental Boulevard MK02-1/HIO
                       Merrimack, NH 03054
                         [phone]
                           decvax!jmcg
                       [e-mail]

For registration or hotel information, contact:

Judith F. DesHarnais
USENIX Conference Coordinator
PO Box 385
Sunset Beach, CA 90742
[phone]
usenix!judy

Volume-Number: Volume 11, Number 88

From usenet  Wed Jul  8 11:52:19 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA00526; Wed, 8 Jul 87 11:52:19 EDT
From: Kenneth Almquist <gatech!opus!ka>
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Message-Id: <[e-mail]>
Sender: ut-sally!std-unix
Reply-To: gatech!opus!ka (Kenneth Almquist)
Date: 5 Jul 87 00:49:11 GMT
Apparently-To: std-unix-archive

From: [e-mail]@opus.uucp (Kenneth Almquist)

OK, here is a simple, backward compatible fix to the tar format.  When
tar encounters a file name which is a link to a file that it previously
dumped, it should first write out a header for the file indicating that
it is a link to a previously dumped file.  It should then write out
another header for the file, this time without linkflag set, and follow
this header with the contents of the file.  This way, if the first link
to a file is not dumped, its contents will be available later when
subsequent links are dumped.

This is backward compatible because an old version of tar would make the
link when it read the first header, and then dump the contents of the
file when it read the second header.  Dumping the contents of the file
does no harm because is will not modify the contents of the file.  Of
course, new implementations of tar might want to recognize this situation
and avoid dumping the contents of the file, but only for reasons of
efficiency.

I noted Marc Mengel's suggestion that tar write out the contents of a file
when the last link to a file is encountered, rather than the first.  This
would be nice, but I don't see how it could be done in a way that is
backward compatible with the current tar format.  I also read Michael
Gersten's article suggesting that tar could rewind raw magnetic tapes by
closing them and openning them again.  This proposal doesn't deal with
the question of how cpio could be made to use the tar format, since cpio
reads from its standard input, which it has no way of closing and openning
again, and it also ignores the case where tar is reading from a pipe
because the tape drive is not on the same machine that tar is running on.
So I feel that the above change to the tar format is necessary.

The remaining problem with the tar format is the limit on the file name
size.  If memory serves, cpio originally limited file names to 127 char-
acters, and this was recognized as inadequate and increased to 255 char-
acters.  The current maximum file name in tar is 99 characters.

However, the maximum file name supported by tar can be increased while
still allowing files whose names are not more than 99 characters long to
be read by existing implementations.  I will suggest one possibility here.
Increase the size of the linkname field to 200 characters.  Since this
field is at the end of the header structure, this will not alter the
location of any of the other fields.  Place a 100 character name exten-
tion field after the linkname field.  If the file name field does not
contain a nul terminator, the remainder of the file name is assumed to
be in the file name extention field.  This scheme allows file names of
up to 199 characters to represented, which comes close to the 255
character limit of the current cpio implimentation.  It leaves 55 bytes
of the header free for future expansion.

These changes to the tar format would make it possible to write a program
which used the tar format, but otherwise behaved exactly like cpio except
for a slight decrease in the maximum file name length.

I still don't like it, mind you.  I receive a lot more programs over the
net than I do via tape, and here tar fails miserably because it has nul
characters in the header which news and mail programs cannot handle.  It
is hard to get excited over a standard that fails to handle the most
common case (or more accurately, what is the most common case for me).
But I agree with Henry Spencer's statement that the role of standards
committees should be to standardize existing practice, with at most minor
changes.  So we should either forget about developing a standard now, or
standardize on the most widely available format (which is tar) after fixing
the major problems with it.  I could go for either approach.
                Kenneth Almquist

P.S.  A lot of nonsense has appeared in this group about the supposed
      deficiencies of cpio, which I won't rebut since I don't support
      using the cpio format as a standard.  Just please take it all with
      a grain of salt.

[ I'd rather have details than innuendo, thanks.  -mod ]

Volume-Number: Volume 11, Number 89

From jsq  Wed Jul 15 00:19:37 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA10594; Wed, 15 Jul 87 00:19:37 EDT
From: Marc W. Mengel <cuuxb!mmengel>
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Message-Id: <[e-mail]>
References: <[e-mail]>
Sender: [e-mail]
Reply-To: cuuxb!mmengel (Marc W. Mengel)
Organization: AT&T-DSD, System Engineering for Resellers, Lisle IL
Date: 13 Jul 87 18:30:17 GMT
Apparently-To: std-unix-archive

From: [e-mail] (Marc W. Mengel)

In article <[e-mail]>;
>I noted Marc Mengel's suggestion that tar write out the contents of a file
>when the last link to a file is encountered, rather than the first.  This
>would be nice, but I don't see how it could be done in a way that is
>backward compatible with the current tar format.


Maybe I was too brief in my attempt at describing it... What you do
is make two recursive descents of the directory tree.

In the first recursive descent, you generate a table that looks like

    file id #    last place seen in recursive descent
    123        foo/bar/baz
    333        foo/baz/bleem
...

Each time you encounter a file in the recursive descent you either add it
to the list, if its file id # isn't there, or replace its pathname in
the second half of the table.

In the second recursive descent, you look up each file you see in the table,
(by file id #) and if its path-from-the-table matches the current path,
you write out the file on the archive, otherwise you mark the current
path as a link to path-from-the-table in the archive.

Since our two recursive descents of the file tree should be identical, we
should always have only the last reference to a given file with data, and
all earlier references to that file listed as links to the one later on
the archive.

(Of course we only need to put files in the table that have multiple
links...)

So I am asking that a notation be put in the tar archive format for a
link to another file in the archive, along with the requirement that
link-to-file-"foo" nodes in the archive must always precede file-"foo"
nodes.


[ If you want to make a proposal to the P1003.1 Working Group,
you need to supply actual wording for the standard.  -mod ]

--
 Marc Mengel
 attmail!mmengel
    or
 ...!{moss|lll-crg|mtune|ihnp4}!cuuxb!mmmengel


Volume-Number: Volume 11, Number 90

From jsq  Wed Jul 15 00:43:51 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA10744; Wed, 15 Jul 87 00:43:51 EDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: Re: tar vs. cpio
Message-Id: <[e-mail]>
Organisation:  USENIX Association
Date: 15 Jul 87 04:43:41 GMT
Apparently-To: std-unix-archive

From: usenix!jsq (John S. Quarterman)

A belated report about the Seattle P1003 meeting,
regarding section 10.

No one proposes non-ASCII cpio format any more.

A revised cpio proposal was received.  It is in
appropriate format for P1003.1, but is still straight
System V cpio.

The proposer of that proposal has agreed to supply
an updated proposal, including optional extensions
for symbolic links, contiguous files, and a general
method of extension.  This is analogous to what is
already in Draft 10 about the ustar format.

P1003.1 Draft 11 will include the updated cpio proposal
in addition to the already-present ustar format.

Some notes have been moved from Section 10 into the Rationale.

The introductory matter in 10.1 about the user of permission
information on extraction of archives has been reworded, mostly
to avoid the word "utility" (this is 1003.1, i.e., the programming
language interface standard, that we are discussing.)

A note is expected from X/OPEN to address the issues raised in my
previous note (IEEE 1003.1 N.100, "tar vs. cpio"), and to include
some comments about the motivation for the cpio proposals.

The cpio proponents have been invited to post that note and
the new cpio proposal in this newsgroup.

N.100 will appear in the next issue of ;login:, the Newsletter
of the USENIX Association.  The cpio proponents have been
invited to submit equivalent material.  There is a possibility
that similar articles may appear in the EUUG newsletter.


An actual decision on what format(s) will be in the IEEE 1003.1
Full Use Standard is expected at the September meeting in
Nashua, New Hampshire.  Though, of course, there is still the
possibility that it will be determined in actual balloting.

[ Note that I am posting this report as the USENIX Institutional
Representative to IEEE P1003, not as the moderator.  Replies
and related submissions are solicited.  -mod ]

Volume-Number: Volume 11, Number 91

From jsq  Sat Jul 18 13:15:40 1987
Received: by uunet.UU.NET (5.54/1.14)
    id AA13718; Sat, 18 Jul 87 13:15:40 EDT
From: [e-mail] (Moderator, John Quarterman)
Newsgroups: comp.std.unix
Subject: End of Volume 11
Message-Id: <[e-mail]>
Reply-To: [e-mail]
Date: 18 Jul 87 17:15:32 GMT
Apparently-To: std-unix-archive

This is the last article in Volume 11 of comp.std.unix.
Volume 12 will start immediately.

Volume-Number: Volume 11, Number 92