From mboxrd@z Thu Jan  1 00:00:00 1970
Message-ID: <1f2bc8a46d1a25563d56b9fcce150ce4@plan9.bell-labs.com>
From: presotto@plan9.bell-labs.com
To: anyrhine@cs.helsinki.fi, 9fans@cse.psu.edu
Subject: Re: [9fans] tar.c, should use readn() instead of read().
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Date: Mon, 12 Aug 2002 10:04:34 -0400
Topicbox-Message-UUID: da8ebeaa-eaca-11e9-9e20-41e7f4b1d025

On Mon Aug 12 05:06:19 EDT 2002, anyrhine@cs.helsinki.fi wrote:
> tar's readtar() -function uses read(), where it should use readn(). This
> causes problems when piping to tar from a program that doesn't write() in
> multiples of 512.

Tar's input is quite odd.  It tries to feel out the buffer size it
can use (in multiples of 512) when reading from a file specified
by the -f option and otherwise uses 1*512.  That means if you say

	tar -x -f /fd/0 < file

instead of

	tar -x < file

you get different size reads.  The same happens when writing, i.e.,
with the c and r options so at least its consistent.  I looked
through the dump and it was that way in 1997 so its not a recent change.
In fact, a 'man tar' on an SGI Unix shows the same behavior so its
probably an inherited bias.

I'm not quite sure of the motivation between the difference.  It
seems a bit silly to me since its just buffering and doesn't have
anything to do with semantics.  Writing-to/reading-from raw tape
drives (and newer media) does have size restrictions so I understand
the feeling out of the read size.  However, I'm not sure why
the stdin/out should be limited to such a small buffer size, perhaps
a throwback to limitations long gone.

Of course, this has little to do with the complaint except that
I don't want to change things till I understand what's really
happening.  Then I may end up changing it a bit more radically
or just fix the man page to say that input has to be a
multiple of 512 bytes.