In message <200406201727.i5KHRBM21275@srapc342.sra.co.jp>, Noriyuki Soda writes
:
>>>>>> On Mon, 21 Jun 2004 02:11:23 +0900 (JST),
>	Noriyuki Soda <soda@sra.co.jp> said:
>
>> Well, I guess what you really meant to do is the following:
>> 	gzip -dc image.gz | dd of=/dev/rwd0d obs=16k conv=osync
>
>Oops, I missed the following part of your mail:
>
>>>>>> On Sun, 20 Jun 2004 18:55:19 +0200,
>	Jukka Salmi <jukka-netbsd@2004.salmi.ch> said:
>
>> Yes, but the file I'm trying to write to /dev/rwd0d is 5242880
>> (== 16k * 320 == 10240 * 512) bytes
>
>In that case, "conv=osync" is not needed, and the following command
>should work:
>
>	gzip -dc image.gz | dd of=/dev/rwd0d obs=16k
>
>> Although I'm not sure why the gzip binary from 1.6.2 works.
>
>And, hmm, I guess GNU gzip is doing buffering at output side,
>but gzip in -current does not.
>
>Matt,
>Isn't it better to do the buffering for compatibility with GNU gzip?

I'm 90% certain that there is no guarantee of buffering strategy, and 
never was.  Portable scripts do things like the dd strategy shown 
above.  It worked on 1.6.2 by coincidence.

That said, pragmatism may dictate changing -- *not* fixing -- gzip, but 
probably not if the cost of doing so is too high.

		--Steve Bellovin, http://www.research.att.com/~smb