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, ...)


_______________________________________________
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Reply via email to