the same limitation exist for ethereal. In
particular what i have written below is correct.
Any suggestion or corrections are welcome
________________
As ethereal uses the standard I/O library to read
capture files, the
standard I/O library routines may impose limitation
on size.
ANSI C requires that fseek and ftell operate with a
long int file
offset (off_t). On an implementation with 32-bit ints,
this means they
only work up to 2 GB. On such implementation thereal won't be
able to
read/write capture files > 2GB
This isn't really a operating system
limitation. It isn't even a POSIX limitation, per se.
The source of
this limitation is _ANSI/ISO Standard C_ which specifies that
the offset for
fseek() is a "long". They went to the trouble of defining
"fpos_t" for
fgetpos() and fsetpos() (which could be typedef'd to a "long
long"), but
overlooked fseek(). *This* is why 32-bit UNIXs have the 2GB
file size
limit -- unless you resort to some non-ANSI-C scheme. (Sun, HP,
IBM,
and others agreed on such a kludge, something like open64(),
fseek64(), etc.,
probably combined with a special status bit in the inode.)
BTW, POSIX did the
right thing with a typedef'd offset "off_t" for lseek().
_If you limit your file I/O to ANSI/ISO C_, you
will get problems on
Win32/NTFS also.
LINUX
-----
To support files larger than
2 GiB on 32-bit systems, , a number of changes to kernel and C library have to
be done.
This is called Large File Support (LFS). The support for LFS is not
yet complete in Linux but to use LFS ethereal should
probably be compiled
with
LFS options (SUSE 7.1 and RH7.1 have limited LFS support)
Window
-----
By design, all versions of Win32 (Win9x/ME/NT/2000)
provide full support
for 64bit pointer file operations. Means for 64bit
support, the right file
pointer structure is to be passed, that is, ethereal
code be modified .
But original ethereal will supoort only 2 GB
files
_______________________
Naveen