From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@cse.psu.edu From: "Douglas A. Gwyn" Message-ID: <3D587D23.3826ACB0@null.net> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit References: <1f2bc8a46d1a25563d56b9fcce150ce4@plan9.bell-labs.com> Subject: Re: [9fans] tar.c, should use readn() instead of read(). Date: Tue, 13 Aug 2002 09:31:08 +0000 Topicbox-Message-UUID: db7ecb48-eaca-11e9-9e20-41e7f4b1d025 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).