two tar issues: man page and --totals behaviour

[Stefan A. Deutscher]

On Fri, Jun 11, 2004 at 08:50:17AM -0400, Lowell Gilbert wrote:
> "Stefan A. Deutscher" <sa.deutscher at tiscali.de> writes:
> 
> > Hi folks,
> > 
> >   just noticed two issues with tar on FreeBSD 5.1 (actually, it is
> > GNU tar 1.13.25):
> 
> It's a heavily modified version of Gnu tar, actually.
> 
> > (1) The man page is somewhat out of sync with what tar --help shows
> >     in terms of options
> > 
> >     Should I submit a PR for that one, or send a bug report to the gnu
> >     tar maintainers, or both?
> 
> The man page isn't a primary documentation method; the *real* manual
> is in Gnu info.  ["info tar"]  It's probably the local (FreeBSD)
> changes that haven't gotten documented.

Ah, didn't think of info. Usually, man pages which have been abandoned
in favour of online info docs do say so. Will try to submit a patch for
that one, at least :-)


> > (2) The option --totals, according to the docs and --help, is supposed
> >     to show the bytes _written_. It does not quite:
> > 
> >     - When running plain 'tar c', it actually shows the bytes written.
> > 
> >     - When running tar with any of the built-in compression flags, such
> >       as 'tar -c -{z,Z,y}', it shows the exact same number of bytes as
> >       when invoked without these flags.
> >       
> >     While, technically, it might show the bytes written _to_ the
> >     compression program, for all practical purposes it appears to show
> >     what was _read_ from disk. The space used on tape may be
> >     significantly smaller.
> > 
> >     I understand that for backwards compatibility one cannot just change
> >     the behaviour of this flag from one day to another. Fixing the docs
> >     might be the easy way out, but I'd like to suggest the addition of
> >     some flag that reports what was actually written _to_ the tape
> >     device.
> > 
> >     Even if the device-internal HW compression may change what actually
> >     ends up on tape (i.e. compressing uncompressed stuff somewhat while
> >     probably not gaining anything on gzip or bzip2), this would give a
> >     better indicator of tape usage and space left on a tape.
> 
> This would be fairly tricky to implement with an external compression
> filter in software, never mind in hardware.

Hm. I thought tar talk to the tape directly, even when it invokes an
external (or internal) compression algorithm? If it was to do something
like 'tar cf - . | gzip -dc - | dd if=- of=/dve/sa0' I'd understand that
counting what hits the tape _device_ from within tar is next to
impossible. However, I didn't see it do that. So, if tar talks to the
tape device directly and sends it blocks of (compressed) data, it
shouldn't be too hard to have it count 'em as well?


> >     I have no idea whether this  has been discussed here already, google
> >     didn't like me enough to turn up relevant threads. Nor do I know how
> >     the upcoming bsdtar handles that flag's behaviour.
> 
> I don't think bsdtar has such a flag, actually.
> 
> >     Again, should I submit  a PR for that one, or send a bug report to
> >     the gnu tar folks, or both?
> 
> If you have written the code to do what you're saying, please do
> submit it.  

Don't have any code to submit and didn't even look at the code yet. But
it does make a worthwhile project for one of those rainy evenings, I'll
put it on my to do list.

 Cheers,
            Stefan