Huge thanks to our Platinum Members Endace and LiveAction,
and our Silver Member Veeam, for supporting the Wireshark Foundation and project.

Wireshark-bugs: [Wireshark-bugs] [Bug 1190] over 2GBytes files have incorrect size in the open d

Date: Fri, 12 Nov 2010 15:55:36 -0800 (PST)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1190

Robert Bullen <robert@xxxxxxxxxxxxxx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |robert@xxxxxxxxxxxxxx

--- Comment #10 from Robert Bullen <robert@xxxxxxxxxxxxxx> 2010-11-12 15:55:31 PST ---
Until zlib addresses their file size limitations, I think a possible interim
solution would be to only use zlib for files that need it. The 2 GB file size
is a limitation of the zlib format, and it need not be imposed upon all trace
file formats.

What do I mean by imposing the limit on other formats? I investigated why
editcap failed to split an uncompressed 10 GB file into smaller pieces about 2
GB of the way in. If I understand the code correctly, when the Wireshark tool
suite is compiled with zlib then all file I/O goes through the zlib routines
(via the file_wrappers.h/c isolation layer), regardless of whether the file is
compressed. Thus subjecting all file formats to the size limitation. When I
compiled without zlib, the attempt at splitting the 10 GB file succeeded.

It should be stressed that this issue affects all callers of the wiretap
library. For example, editcap and capinfos. Those tools are much more likely
than Wireshark and tshark to be invoked on large trace files since Wireshark
and tshark have little hope of opening large files to completion thanks to the
aforementioned memory consumption issues. So perhaps this issue is more serious
than originally classified.

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.