From owner-freebsd-arch@FreeBSD.ORG  Wed Jan 14 21:38:07 2004
Return-Path: <owner-freebsd-arch@FreeBSD.ORG>
Delivered-To: freebsd-arch@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 21A4616A4CE; Wed, 14 Jan 2004 21:38:07 -0800 (PST)
Received: from gw.catspoiler.org (217-ip-163.nccn.net [209.79.217.163])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 3300443D5E; Wed, 14 Jan 2004 21:38:02 -0800 (PST)
	(envelope-from truckman@FreeBSD.org)
Received: from FreeBSD.org (mousie.catspoiler.org [192.168.101.2])
	by gw.catspoiler.org (8.12.9p2/8.12.9) with ESMTP id i0F5bo7E041482;
	Wed, 14 Jan 2004 21:37:54 -0800 (PST)
	(envelope-from truckman@FreeBSD.org)
Message-Id: <200401150537.i0F5bo7E041482@gw.catspoiler.org>
Date: Wed, 14 Jan 2004 21:37:50 -0800 (PST)
From: Don Lewis <truckman@FreeBSD.org>
To: tjr@FreeBSD.org
In-Reply-To: <20040114234829.GA19067@cat.robbins.dropbear.id.au>
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
cc: freebsd-arch@FreeBSD.org
cc: kientzle@acm.org
Subject: Re: Request for Comments: libarchive, bsdtar
X-BeenThere: freebsd-arch@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Discussion related to FreeBSD architecture
	<freebsd-arch.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-arch>
List-Post: <mailto:freebsd-arch@freebsd.org>
List-Help: <mailto:freebsd-arch-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-arch>,
	<mailto:freebsd-arch-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Thu, 15 Jan 2004 05:38:07 -0000

On 15 Jan, Tim Robbins wrote:

> - Padding gzip'd tar archives (with bsdtar czf) causes gzip to report
>   "trailing garbage" and fail, and in turn this causes GNU tar to fail.
>   BSD pax (-wzf) and GNU tar (czf) do not pad compressed archives.

In the case of GNU tar, it depends on where it is writing.  It pads when
writing to stdout, but does not pad when writing to a file.  I would
hope that it pads when writing to a tape device, since many tapes
require writing to some multiple of their native block size.

% tar cfz /tmp/printcap.tgz /etc/printcap
tar: Removing leading `/' from member names
% ls -l /tmp/printcap.tgz
-rw-r--r--  1 dl  wheel  1216 Jan 14 21:28 /tmp/printcap.tgz
% tar cfz - /etc/printcap > /tmp/printcap.tgz
tar: Removing leading `/' from member names
% ls -l /tmp/printcap.tgz
-rw-r--r--  1 dl  wheel  10240 Jan 14 21:28 /tmp/printcap.tgz

I would prefer to have explicit control of this behavior.

BTW, on a Unix variant that I used many years ago, there was an enhanced
version of dd, called ddx, which had the useful option "mobs", which was
used to specify a minimum output block size.  You could run something
like
	ddx obs=10k mobs=1k ...
to cause all writes to be blocked to 10k except for the last partial
write which would be padded out to at least 1k.  I don't remember what
it did if there was 1025 bytes left over for the last write ...