🚀 go-pugleaf

From:  guy@auspex.uucp (Guy Harris)

>How about because the semantics of operations permitted on POSIX file
>descriptors are a poor match for many transport providers? Read()/write()
>are stream operations; only TCP is a stream transport provider. OSI TP0/2/4
>maps much more closely to stdio and fgets()/fputs() in that it is
>record-oriented.

Standard I/O, and "fgets()"/"fputs()" in particular, are
record-oriented?  News to me; I thought standard I/O offered byte
streams, and "fgets()" read stuff from that stream until it hit a
newline or EOF, and "fputs" put bytes from a string out onto that
stream.

For that matter, raw magtapes are also record oriented, and "read()" and
"write()" work fine on them.  I don't see the problem with TPn; a single
"write()" could either be turned into one packet, or broken up
arbitrarily into N packets if there's a maximum packet size.  If you
*want* to have a correspondence between "send it" calls and records, I
see no problem with providing additional calls to do that, but I also
don't see any problem with hiding record boundaries, if necessary, from
applications that *want* to just send byte streams over TPn.

>What does it mean to seek() on a network endpoint?

What does it mean to "seek()" on a tty?

Volume-Number: Volume 20, Number 96

From:  peter@ficc.ferranti.com (peter da silva)

In article <770@longway.TIC.COM> From: jason@cnd.hp.com (Jason Zions)
> Read()/write() are stream operations; only TCP is a stream transport
> provider. OSI TP0/2/4 maps much more closely to stdio and fgets()/fputs()
> in that it is record-oriented.

The same is true of a UNIX tty device with canonical processing. So?

> What does it mean to seek() on a network endpoint?

What does it mean to seek() on a pipe?
-- 
Peter da Silva.   `-_-'
+1 713 274 5180.
<peter@ficc.ferranti.com>

Volume-Number: Volume 20, Number 94

From:  henry@zoo.toronto.edu (Henry Spencer)

>From:  Jason Zions <jason@cnd.hp.com>
>How about because it constrains implementations to make DNI
>kernel-resident?

Nonsense.  Nothing in 1003.n constrains implementations to make anything
kernel-resident.  Things like read() are functions, which may or may not
reflect the primitives of the underlying kernel.  They are merely required
to communicate -- somehow -- with something that performs the required
services.

Why have two different kinds of endpoints for I/O?  We already have one
which is general enough to encompass almost every kind of I/O under the sun.

>How about because the semantics of operations permitted on POSIX file
>descriptors are a poor match for many transport providers? Read()/write()
>are stream operations; only TCP is a stream transport provider. OSI TP0/2/4
>maps much more closely to stdio and fgets()/fputs() in that it is
>record-oriented. What does it mean to seek() on a network endpoint?

Read()/write() are stream operations that work perfectly well as record
operations too.  As witness Unix ttys, which are record-oriented devices
on input, and Unix magtapes, which are record-oriented both ways.  As for
what it means to seek on a network endpoint, exactly the same as it means
to seek on a tty:  probably nothing.  But why invent new mechanisms for 
I/O when the old ones will do perfectly well?

"Don't fix it if it ain't broken."

                                         Henry Spencer at U of Toronto Zoology
                                          henry@zoo.toronto.edu   utzoo!henry

Volume-Number: Volume 20, Number 93

From:  Dominic Dunlop <domo@tsa.co.uk>

In article <754@longway.TIC.COM> gwyn@smoke.brl.mil (Doug Gwyn) fulminates
> The ANSI magtape format is simply inappropriate.  UNIX archives were
> designed to be single files, making it simple to transport them by
> means other than magnetic tape.  In this modern networked world, for
> the most part magnetic tape is an anachronism.  Any archive format
> standard for UNIX should not depend on the archive supporting
> multiple files, tape marks, or any other non-UNIX concept.

Er.  As Jason Zions points out in <770@longway.TIC.COM>,
> A significant branch of the UNIX(tm)-system and POSIX research community
> believes "All the world's a file"; the Research Unix V.8 and Plan 9 folks
> are among the leaders here. I feel only slightly squeamish about accusing
> them of having only a hammer in their toolbelt; of *course* everything
> looks like a nail!

The network as a featureless data stream is another example of the same
``traditional'' thinking in the UNIX community.  Actually, the
datagram-based schemes favoured in the US (oversimplifying grossly, we
Europeans have a preference for connection-based systems which do deliver
streams) can provide nice record boundaries, which could in turn be used to
delimit labels for the proposed tape archive format (after adding some
reliability and sequencing).  Just because the format is based on IS 1003
for labelled magnetic tapes does not mean to say that it cannot be used on
other media, networks among tham.  After all, tar's a format for blocked
magnetic tapes, but that hasn't stopped us moving tar archives over
networks.
-- 
Dominic Dunlop

Volume-Number: Volume 20, Number 96

From:  Doug Gwyn <gwyn@smoke.brl.mil>

In article <781@longway.TIC.COM> uunet!tsa.co.uk!domo@usenix.ORG writes:
>After all, tar's a format for blocked magnetic tapes, ...

No, it is not.  A "tar" archive is merely a stream of bytes, all of
whose structure is contained internally.  The designers of "tar" and
(to a lesser extent) "cpio" archive formats did, however, take into
account the blocked nature of such media, so that it would be
convenient to use such media to hold the archive.  This was entirely
appropriate and does not require that such media be used.

Volume-Number: Volume 20, Number 97

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 125

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