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

[Tamás Varga <Tamas.Varga () ericsson com>]

Hello Guy,

Based on your description, it seems that handling >2GB files is complex to support on 32-bit systems. From this aspect, 
I agree that there is a gap between expectations and user desire. Maybe, bridging this gap by intercepting EOVERFLOW 
and displaying a warning/error is more user-friendly, than displaying the negative value or the default error message. 
Anyhow, I have learnt the behavior and it is acceptable.

cheers,
 Tamas
 

-----Original Message-----
From: wireshark-users-bounces () wireshark org [mailto:wireshark-users-bounces () wireshark org] On Behalf Of Guy Harris
Sent: Tuesday, October 26, 2010 10:21
To: Community support list for Wireshark
Subject: Re: [Wireshark-users] Wireshark (1.4.0) fails opening large file on Windows Vista 32-bit.


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
___________________________________________________________________________
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