9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
* [9fans] tar.c, should use readn() instead of read().
@ 2002-08-12  8:59 Aki M Nyrhinen
  0 siblings, 0 replies; 4+ messages in thread
From: Aki M Nyrhinen @ 2002-08-12  8:59 UTC (permalink / raw)
  To: 9fans

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.


^ permalink raw reply	[flat|nested] 4+ messages in thread
* Re: [9fans] tar.c, should use readn() instead of read().
@ 2002-08-12 14:04 presotto
  2002-08-13  9:31 ` Douglas A. Gwyn
  0 siblings, 1 reply; 4+ messages in thread
From: presotto @ 2002-08-12 14:04 UTC (permalink / raw)
  To: anyrhine, 9fans

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.


^ permalink raw reply	[flat|nested] 4+ messages in thread
* Re: [9fans] tar.c, should use readn() instead of read().
@ 2002-08-12 15:09 Russ Cox
  0 siblings, 0 replies; 4+ messages in thread
From: Russ Cox @ 2002-08-12 15:09 UTC (permalink / raw)
  To: 9fans

> 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



^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2002-08-13  9:31 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2002-08-12  8:59 [9fans] tar.c, should use readn() instead of read() Aki M Nyrhinen
2002-08-12 14:04 presotto
2002-08-13  9:31 ` Douglas A. Gwyn
2002-08-12 15:09 Russ Cox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).