Unix Programming - Re: Whats the practical maximum file size using indexed allocation

This is Interesting: Free IT Magazines  
Home > Archive > Unix Programming > February 2006 > Re: Whats the practical maximum file size using indexed allocation





You are viewing an archived Text-only version of the thread. To view this thread in it's original format and/or if you want to reply to this thread please [click here]

Author Re: Whats the practical maximum file size using indexed allocation
Logan Shaw

2006-02-26, 5:51 pm

Jordan Abel wrote:
> On 2006-02-24, Gordon Burditt <gordonb.l20vx@burditt.org> wrote:
>
> I bet he uses Linux. Linux has traditionally maintained two separate and
> parallel APIs, one in which off_t is a 'long' (32 on a 32-bit system),
> the other in which it's 64 bits. llseek is one of the underlying system
> calls for the latter mode, and it is also sometimes misused (where
> lseek64 _should_ be used) to be able to access files in "large file"
> mode in the former. O_LARGEFILE (misspelled above as O_LARGE) is a bit
> used internally by open64() which is also sometimes misused in the same
> way.


Just a data point: on Solaris 8 (and presumably later versions as well
since Sun is anal-retentive about keeping interface compatibility at
both the binary and source levels[1]), the documentation says that
calling open() with O_LARGEFILE is equivalent to calling open64(),
which to me indicates that using O_LARGEFILE with open() is kosher.
Solaris also maintains a parallel set of APIs, so that 32-bit
applications can use either 32-bit or 64-bit file offsets, so Linux
isn't unique in that regard. (I don't even think Linux was first,
but I can't remember.)

- Logan

[1] which, by the way, is a good thing in many cases
Sponsored Links






Free braindumps | Software forum | Database administration forum

Copyright 2003 - 2008 webservertalk.com