[ On Mon, December 11, 1995 at 16:03:11 (+1030), Ian Dall wrote: ]
> Subject: Re: Tapeboot problem SOLUTION
>
> The unix semantics only guarantee that you can read at least one byte
> from a pipe unless it is EOF, in which case you read zero bytes. In
> practice the bsd socket code transfers data in chunks.

Hmm....

Well, we don't have to argue about this for SunOS-4 or 4.4BSD
derivatives such as NetBSD, since pipes are implemented as socket pairs
and the manual pages for write(2) and pipe(2) do seem to make guarantees
about this.

However I would like to point out that UNIX v10 guarantees that writes
of the appropriately small enough number of bytes to a pipe "are
contiguous even if many processes are writing.  Writes introduce a
record structure: a read will not return bytes from more than one write;
see read(2)."  I'm unsure how they implement pipes.

Indeed the SysV manuals don't make this promise, nor does it seem to be
so according to Bach or Stevens in "UNIX Network Programming", but I can
say that from past experience this record structure is indeed there.

>   >   gunzip < netbsd-rd.gz | dd ibs=512 obs=8k of=$T conv=sync
> 
> The ibs is redundant because it is the default. The last block
> being shorter than the block size could cause problems on devices
> with variable block sizes (exabytes and dat tapes for example) but
> otherwise should work in practice.

But because of the "conv=sync" the last block will not be of variable
size.  It will be exactly 512 bytes (i.e. equal to ibs).

-- 
							Greg A. Woods

+1 416 443-1734			VE3TCP			robohack!woods
Planix, Inc. <woods@planix.com>; Secrets Of The Weird <woods@weird.com>