Wireshark-dev: [Wireshark-dev] Changing capture file offsets to 64bits - please distclean your
From: Ulf Lamping <[email protected]>
Date: Sun, 05 Nov 2006 23:48:51 +0100
Hi List!

I'm currently trying to fix bugzilla 1190: "over 2GBytes files have incorrect size in the open dialog and status bar".
It boils down to replace all appearances of file offsets from currently 
long to gint64.
I've (hopefully) replaced all such offsets in wiretap (bumped version to 
0.3.1) and elsewhere (summary output, frame dissector, ...).
What still needs to be done:

A
- The zlib implementations of gzseek() and gztell() ( wiretap/file_wrappers.c) still use the "traditional" long and casts them to gint64 in and out. This obviously will fail for files > 2GB. - need to rewrite the zlib "file functionality" which is also desirable as the current implementation is slow for random access
B
- The unix implementations of fseek() and ftell() ( wiretap/file_wrappers.c) still use the "traditional" long and casts them to gint64 in and out. This obviously will fail for files > 2GB. - hopefully easily solved by an experienced unix developers (which I'm not) - probably using getFilePos() and setFilePos()
C - Fix any new bugs I've introduced - please mail them to the list.

D - test on other file formats than libpcap (buildbot will hopefully do the job :-)

So in it's current situation, 2GB files can only be opened correctly on Win32 platforms with a build not including zlib ...
... yet another small step towards a stable wiretap API (all remaining 
changes should be possible inside wiretap without changing the API) :-)
Regards, ULFL


P.S: Some thoughts about replacing the zlib file handling with our own implementation: - use low/level IO functions only (using stream I/O is only currently used to solve UTF8 to UCS16 filename conversion on Win32 on open calls)
- 64bit seek and tell - optimized for random access
- using other compression than gzip only (zip, bz2, ...)