On Mon, Jun 12, 2000 at 10:08:55PM -0400, Lars Nordin wrote:
-> I thought it was a kernel/glib/filesystem issue that really didn't have much
-> to do with the word size of the hardware.
-> You would figure that you could have the kernel compensate by doing the
-> pointer/offset math 32-bits at a time and hence enable it to do a lseek on a
-> 64 bit value on IA32 hardware (it would be slower); Especially since they
-> have filesystems that are larger than 2GB (32bits) but it's been too long
-> since I worked at that low of a level.
I don't think it is just a library issue. For one thing, I believe in
order to be POSIX compliant, you have to be able to seek from any point in
a file to any other in one function call (which is why I immediately
looked at the man page for lseek). To do that for a file of size greater
than 2 GB, you have to have a way to indicate more than 2 GB to the lseek
function, and that means either using a single 64 bit value for the input,
or using (as NT does) two 32 bit values (yucch).
It can be done, obviously. However, either solution would break a lot of
existing programs, so it is the sort of thing to do only at a major
revision.
->
-> ----- Original Message -----
-> From: Charles Curley <[EMAIL PROTECTED]>
-> To: <[EMAIL PROTECTED]>
-> Sent: Monday, June 12, 2000 12:39 PM
-> Subject: Re: [expert] files larger than 2 GB
-> > -> > I would appreciate information about the possibility of creating
-> files
-> > -> > larger than 2 GB.
-> [snip]
-> > It is a Linux kernel limitation on 32 bit architectures (e.g. 80x86)
-> [snip]
-> > I seem to recall somewhere reading that this wil be addressed in the 2.4
-> > kernels. Any kernel watchers care to verify this?
->
--
-- C^2
No windows were crashed in the making of this email.
Looking for fine software and/or web pages?
http://w3.trib.com/~ccurley
