maximum file size of FOPEN

[uremae]

I tried to open some large files in my computer. (ram 512MB)

1. is there limitation of file size FOPEN?

2. if I have a file that is larger than the maximum size, how can I
open the file?

[zhaokai115]

1. It depends on the system. If the files can exist in your computer,
FOPEN can open it.

For FREAD, FWRITE, etc, the limitaion of file size is size_t, it also
depends on the system. In most of the systems, size_t is a 32-bits
unsigned inteter. In such system, the limitation is 4G - 1.

[zhaokai115]

1. It depends on the system. If the files can exist in your computer,
FOPEN can open it.

For FREAD, FWRITE, etc, the limitaion of file size is size_t, it also
depends on the system. In most of the systems, size_t is a 32-bits
unsigned inteter. In such system, the limitation is 4G - 1.

[Walter Roberson]

In article <11************ **********@g14g 2000cwa.googleg roups.com>,
<zh********@163 .com> wrote:

For FREAD, FWRITE, etc, the limitaion of file size is size_t, it also
depends on the system. In most of the systems, size_t is a 32-bits
unsigned inteter. In such system, the limitation is 4G - 1.

According to opengroup.org the limit is off_t which is a type
specifically for file sizes -- and it is a signed type.
fseek can return (off_t)-1 when the seek is not meaningful, so
it cannot be an unsigned type.

opengroup.org classifies off_t as an "extended signed integral type".
An "extended" integral type isn't limited to the usual short/int/long
types, provided that the type has "the same properties".
[For this purpose, it helps to remember that the UNIX98 specification
predates C99's formalization of the existance of 'long long'.]
--
Oh, to be a Blobel!

[David Mathog]

uremae wrote:

then how can I read the large file that is larger than gigabye with
what system-specific calls in linux or unix.

It's also worth mentioning that if stream processing is all
you're after then you can read a file of any size through a pipe.
For instance:

cat hugefile | processit > outfile

should work no matter how large hugefile is.
Processit just reads from stdin and writes to stdout
using standard C I/O functions. This assumes that
"cat" can read the huge file, but I've not yet
encountered a linux/unix system where cat cannot
do so.

Regards,

David Mathog
ma****@caltech. edu

[Dave Thompson]

On 19 May 2005 21:57:05 GMT, ro******@ibd.nr c-cnrc.gc.ca (Walter
Roberson) wrote:

In article <d6**********@n wrdmz02.dmz.ncs .ea.ibs-infra.bt.com>,
Malcolm <re*******@btin ternet.com> wrote:

"uremae" <ur****@gmail.c om> wrote

1. is there limitation of file size FOPEN?

There's ususally some limit, though it might be so large that there is no
chance of exceeding it.

Could you give us an example of a system with such a limit, Malcolm ?

I have certainly run into systems whose filesize was limited
(with different limits for different filesystem types), but I
cannot think of anything in C or POSIX.1 or any implementation
that I have -encountered- that would fopen() for opening a

IAYM would _fail_ or _reject_ or somesuch on the fopen.
[plain] file for read once the file had made it on to the
filesystem.

Not an actual example, but one idea of how someone might conceivably
get into such a fix:

Multics had normal files limited to 256KW = 1MB (of 9 bits) and there
was no easy way to increase this because files were tied to (most)
segments in the virtual memory. For people who needed bigger there
was a feature/kludge called "multi segment files" which treated a
directory -- IIRC specially marked -- containing multiple actual files
as one big file, but support for this feature was apparently uneven,
working in some programs and not others. (My information on this is
secondhand; I was a lowly student user so my quota didn't reach even
to one full segment much less many and my access didn't extend to any,
er, "interestin g" file areas.)

Now I don't know if there was (ever) a C for Multics -- especially
considering its origin -- but if there was or were to be I can imagine
that it might fail for MSFs, and thus apparently for "large files".

- David.Thompson1 at worldnet.att.ne t

[thvv]

There was a C for Multics, late in its life, 1986, Multics release12.0,
documented in Honeywell manual HH07.

You are mistaken about files on Multics. Language library provided
files for PL/I, FORTRAN, COBOL, and C were all supported by the Multics
library I/O module vfile_, which supported various access modes on
objects stored in the file system, called "files." Small instances of
files were indeed stored as "single segment files" and larger ones as
"multi segment files." The system and the runtime library attempted to
make the transition from little files to big invisible to the
application program. As in many systems, it was possible to look behind
the curtain and write code that accessed underlying storage directly in
nonstandard ways. But standard conforming programs in the application
languages would work fine with files of sizes larger than 1MB.