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

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

[Russ Cox]

> 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, on every other system, not specifying an f option
gets you /dev/tape rather than stdin/stdout, which just makes
it even weirder.

Russ

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

[Douglas A. Gwyn]

presotto@plan9.bell-labs.com wrote:
> 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.

512 bytes was the original block size for DECtape, also the cooked
magtape device.  There has been a variety of behavior among various
implementations of "tar" over the years.  Generally I recommend
always specifying blocksize with the "b" option.  If you change the
behavior you are likely to make it harder to exchange archives
across systems, including historical ones such as 7th Ed. Unix (which
some of us still use on occasion).

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

[presotto]

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.

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

[Aki M Nyrhinen]

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.