Re: [9fans] tar.c, should use readn() instead of read().

[presotto@plan9.bell-labs.com]

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.