Date: 11 Jun 2004 08:50:17 -0400 From: Lowell Gilbert <freebsd-questions-local@be-well.ilk.org> To: sad@mailaps.org Cc: freebsd-questions@freebsd.org Subject: Re: two tar issues: man page and --totals behaviour Message-ID: <448yeu5kdy.fsf@be-well.ilk.org> In-Reply-To: <20040609204817.A1736@tiscali.de> References: <20040609204817.A1736@tiscali.de>
next in thread | previous in thread | raw e-mail | index | archive | help
"Stefan A. Deutscher" <sa.deutscher@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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?448yeu5kdy.fsf>