Re: Wireshark (1.4.0) fails opening large file on Windows Vista 32-bit.

[Guy Harris <guy () alum mit edu>]

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


___________________________________________________________________________
Sent via:    Wireshark-users mailing list <wireshark-users () wireshark org>
Archives:    http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
             mailto:wireshark-users-request () wireshark org?subject=unsubscribe