two tar issues: man page and --totals behaviour

[Lowell Gilbert]

"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.

> (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.

>     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.