> [ Adding -z option to pax to recreate the -z option in GNU tar ]
>
> >> But if that is done, please make sure the compression is done BEFORE
> >> the blocking and not after, like GNU tar is doing.  Would be
> >> somewhat more friendly to use with tapes that way...
>
> > Please don't do this.  This would make the netbsd output incompatible
> > with every other tar package utility.  Current, .tar.gz means doing
> > the blocking after since it follows the 'unix way' of doing things
> > with filters.  If you want to add a flag to do blocking on a file by
> > file basis then use a different flag other than -z.
>
> This sounds as though "blocking" means different things to the two of
> you.
>
> The text I quoted with >> above I would take to be using "blocking" to
> refer to tar's tendency to do 10240 bytes per write() call, which
> results in 10240-byte records when the output is directly connected to
> a tape drive[%].  The text I quoted with > seems to be using "blocking"
> to refer to the way tar packages a bunch of files up into an archive.
>
> [%] This assumes a "real" tape device, not one of the more recent (eg,
>     quarter-inch cartridge) devices that are streams of 512-byte blocks
>     rather than streams of records.
>
> As I understand it, there is no disagreement.  The operation I take the
> first person to mean, which I currently think would be acceptable to
> the second person, is
>
> 	bunch of files -> package into archive -> gzip -> blocked writes
>
> ie, the equivalent of traditional "tar cf -" output piped into
> something like "gzip | dd obs=10240", the trailing dd being the point.

That is indeed what I wanted.  Both tar(1) and cpio(1) has blocking
options, but GNU tar applies that BEFORE running it through gzip (as
far as my memory serves), which is a pain when working with (real)
tapes.

But like I said in another message, it has been a while since I checked
this last time, so that might have been fixed in the current version.

Thorsten
--
Thorsten Lockert        | postmaster@sigmasoft.com | Universe, n.:
1262 Golden Gate Avenue | hostmaster@sigmasoft.com |         The problem.
San Francisco, CA 94115 | tholo@sigmasoft.com      |