Subject: Re: bin/695: tar won't restore files that are not writable by owner
To: None <netbsd-bugs@NetBSD.ORG>
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
List: netbsd-bugs
Date: 01/04/1995 19:23:47
[ 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.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu