news@ira.uka.de (07/13/90)
From: news@ira.uka.de
--- archives and tapes ---
First, I have to admit that I haven't read the latest standard's version,
but I do have strong feelings about data archives and transport.
Both tar and cpio are highly deficient for properly moving information
out and in. The first blunder of all is the limited format that does not
take care of long file names. There is a NAMSIZ parameter, so for heaven's
sake reserve sufficient space in the file descriptor of such a transport
archive! That's so fundamental that I will only talk about one other equally
nasty point about these formats, missing archive and volume labelling.
Next, you have to realize that both tar and cpio already do arrange data
in suitable chunks for transfer ('tar' reads 'tape archive'!). There is
no reason in the world why an ANSI tape file shall not be the envelope
for a UNIX-type archive. On the contrary, this will finally, after all
these years offer data labelling, both on the archive and on the tape
volumes. It is unbelievable that today, 1990, i have to look at a piece of
paper with my tar tape, which tells me about a number of archives on the
same medium and their position. Additionally, the ANSI tar standard
provides multi-volume data sets, so yet another stumbling stone can be
forgotten, if we only wrap tar' and cpio' archives in ANSI tape structures
(where tar' and cpio' are improved versions of tar and cpio).
Then, a point often forgotten: There is a real need to select, duplicate,
store data from some external medium (tape) on a different type of machine
than the one the tape is written on / to be read. The proposal above will
make that an easy and safe operation, what cannot be claimed today. (Today,
ypou just have to have a guru around who knows alls kinds of different
machines and how they mix).
Finally: Yes, we do move archives across networks, but for most substantial
transfers of data in and out of our machines there is no adequate replacement
for sequential magnetic media. Posix has to take that into account, or we
will be burdened with those problems of today.
Karl Kleine
FZI Forschungszentrum Informatik, Karlsruhe, West-Germany; kleine@fzi.uka.de
Volume-Number: Volume 20, Number 125guy@auspex.uucp (Guy Harris) (07/15/90)
From: guy@auspex.uucp (Guy Harris) >Then, a point often forgotten: There is a real need to select, duplicate, >store data from some external medium (tape) on a different type of machine >than the one the tape is written on / to be read. The proposal above will >make that an easy and safe operation, Really? The proposal above will deal with moving stuff from a machine with a QIC-150-type 1/4" tape drive that can't write QIC-24 tapes to a machine with a QIC-24-type 1/4" tape drive that can't read QIC-150 or QIC-120 tapes? Neat trick! >what cannot be claimed today. (Today, ypou just have to have a guru >around who knows alls kinds of different machines and how they mix). "The proposal above" seems to be "put a 'tar' or 'cpio' archive as one file within an ANSI-labelled tape." I fail to see how that makes things any better; if the problems are with variations between "cpio" and "tar" formats on different machines, wrapping ANSI labels around the "tar" or "cpio" data doesn't seem to make things any better. If the *real* fix is in the "tar'" and "cpio'" formats you list, what do the ANSI labels buy you other than multi-volume support? >Finally: Yes, we do move archives across networks, but for most substantial >transfers of data in and out of our machines there is no adequate replacement >for sequential magnetic media. By "data" do you mean "data as opposed to programs"? If not, do any of the folks who have retrieved, say, the X11 source via FTP or UUCP have any comments on the above claim? I sucked the entire X11R3 distribution to our site via UUCP; I would have done the same with the X11R4 format, except that somebody already had it and offered to put it on 1/4" tapes - fortunately, a 1/4" format we can read; they put it on a "tar" tape, though, so ANSI tape labels contributed nothing.... I suspect the amount of software moved into our site via UUCP is at least a significant fraction of the amount of software moved into our site via magtapes. Volume-Number: Volume 20, Number 128
rml@hpfcdc.fc.hp.com (Bob Lenk) (07/18/90)
From: Bob Lenk <rml@hpfcdc.fc.hp.com> >The following features were deleted (but are still permitted): > CLK_TCK - non-existent definition imported from ANSI C standard As of 1003.1a/D5 (also ISO/IEC DIS 9945-1.2), CLK_TCK is still required to be defined in <time.h>. It is obsolescent. It is mentioned only in one subclause (4.8.1.5), and is not used to define or describe any other functionality. Most features (such as times() are now described in terms of "clock ticks". Since it is no longer in the C Standard, it is not mentioned in 2.7.1 (as in 1003.1-1988); the index seems to have an erroneous reference to that deleted mention. I don't know of any changes to this since that draft/DIS. Bob Lenk rml@hpfcla.hp.com hplabs!hpfcla!rml Volume-Number: Volume 20, Number 135