gzip -l 4GB limit

[Tim Retout]

Hi,

[I'm not subscribed to bug-gzip, so please CC me.]

I've been trying to find the uncompressed size of gzip files without
decompressing them (to implement a progress bar in some code I'm
writing).  The ISIZE field works, but has two problems:

      * It's modulo 2^32 bits, so for > 4GB the size is wrong.  (See the
        output of gzip -l for instance.)
      * It's stored at the very end of the file, and it would seem more
        convenient to be able to find the original size from the start
        of the file.

There's the ability to add "extra fields" to gzip headers - would it be
appropriate to standardize on an optional extra field that, if present,
can provide the original size of the file without the 2^32 limit of
ISIZE?

Then a patch could be written to store this information if we know the
uncompressed size before compressing.

This issue seems to have come up every so often on the bug-gzip mailing
list over the last few years, but no one has fixed it so far (that I
know of).

Regards,

-- 
Tim Retout
Software Developer

SmoothWall Ltd
1 John Charles Way
Leeds LS12 6QA
United Kingdom

1 800 959 3760 (USA, Canada and North America)
0870 1 999 500 (United Kingdom)
+44 870 1 999 500 (All other countries)

SmoothWall is registered in England: 4298247

This email and any attachments transmitted with it are confidential to the
intended recipient(s) and may not be communicated to any other person or
published by any means without the permission of SmoothWall Limited. Any
opinions stated in this message are solely those of the author. See:
http://smoothwall.net/company/email.php
for the full text of this notice.