Wireshark-users: Re: [Wireshark-users] Wireshark (1.4.0) fails opening large file on Windows Vist
On Oct 26, 2010, at 12:40 AM, Tamás Varga wrote:
> However, there are some issues, I have found no reference neither in wiki nor in bugzilla.
> I suspect this is not the expected behavior with respect to file >2GB:
> - capinfos.exe (Windows 32-bit) displays negative filesize
> - capinfos (Linux 32-bit) stops with "Value too large for defined data type" error
> - editcap (Linux 32-bit) stops with "Value too large for defined data type" error
> - tshark (Linux 32-bit) stops with "Value too large for defined data type" error
> - wireshark (Windows 32-bit) does not display the "Loading..." dialog and does not allow to stop loading a few percent of the file.
It's what I'd *expect* (except on 4.4-Lite-based platforms, such as *BSD and Mac OS X, where off_t was 64 bits from Day One, even on 32-bit processors) from an application that doesn't explicitly make an effort to use 64-bit-capable calls when possible (said calls possibly not being present on older systems, and being different between Large File Summit-style UN*X and Windows).
It's probably not what people would *desire*, though. Fixing it, in ways that support both UN*Xes not derived from 4.4-Lite and that don't support the LFS interfaces, those not derived from 4.4-Lite and that support the LFS interfaces, those that are 4.4-Lite derived, and UN*X, and maintaining support for reading compressed files (for information on how wonderful older versions of libz's compressed file I/O support is, see the comment in wiretap/file_wrappers.c that begins with "OK, now this is tricky."), is non-trivial.
There are other reasons why we might not want to continue to use the gz* routines in libz for reading compressed files (such as support for efficient random access, and support for not getting surprised by various changes to the behavior of those routines), even if we continue to use its routines for uncompressing gzipped data, and that might make "maintaining support for reading compressed files" easier. As for the rest of it, that's probably doable - I think it would involve
1) using AC_SYS_LARGEFILE and AC_FUNC_FSEEKO in the configure script, and whatever the equivalents are for CMake;
2) doing whatever is necessary to be able to handle 64-bit file offsets on large-file-capable UN*X systems;
3) wrapping stat() and company in wsutil routines to do the appropriate i64 versions of those routines on Windows and whatever is necessary on UN*X;
4) wrapping the fseek and ftell routines as necessary to do the appropriate i64 versions of those routines on Windows and whatever is necessary on UN*X.
See, for example:
http://www.unix.org/version2/whatsnew/lfs20mar.html
http://msdn.microsoft.com/en-us/library/14h5k7ff(VS.80).aspx
http://msdn.microsoft.com/en-us/library/75yw9bf3(VS.80).aspx
