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@xxxxxxxxxxxxx [mailto:wireshark-users-bounces@xxxxxxxxxxxxx] 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@xxxxxxxxxxxxx>
Archives: http://www.wireshark.org/lists/wireshark-users
Unsubscribe: https://wireshark.org/mailman/options/wireshark-users
mailto:wireshark-users-request@xxxxxxxxxxxxx?subject=unsubscribe
