[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#32903: [PATCH] Display uncompressed size when testing
From: |
Sergey Ponomarev |
Subject: |
bug#32903: [PATCH] Display uncompressed size when testing |
Date: |
Sun, 4 Nov 2018 21:54:59 +0200 |
Thanks for explanation,
>From user point of view it would be better not to enclose the size
into brackets: it will be easier to parse the output by other tools.
On Sun, 4 Nov 2018 at 21:39, Stephen Kitt <address@hidden> wrote:
> Hi Sergey,
>
> On Sun, 4 Nov 2018 14:49:50 +0200, Sergey Ponomarev <address@hidden>
> wrote:
> > > Alongside the OK message, print the real size in bytes; this provides
> > a way to view the stored file's size when it's larger than 4GiB.
> >
> > You can get a real size by `gzip --list` command. Why to show the size in
> > `gzip --test` output? Almost all other compressors (lzop, xz, bzip2, etc0
> > just shows the same message:
> > filename: OK
>
> "gzip --list" only reports sizes correctly up to 4GiB; see the BUGS
> section in
> the manpage:
>
> The gzip format represents the input size modulo 2^32, so the
> --list
> option reports incorrect uncompressed sizes and compression ratios
> for uncompressed files 4 GB and larger.
>
> > Even more, archive manages and other tools may try to parse the test
> > command output and the change may have some impact.
>
> True, I haven’t checked the impact much — although I’ve been running gzip
> with this patch for a while without adverse effects (but that’s anecdotal).
>
> > > this provides a way to view the stored file's size when it's larger
> than
> > 4GiB.
> > I didn't get it. Can you please elaborate on this: `gzip --list` can't
> show
> > uncompressed size more than 4GiB?
>
> See above.
>
> Regards,
>
> Stephen
>
--
Sergey Ponomarev <https://linkedin.com/in/stokito>, skype:stokito