William Lee Irwin III writes:

if (!(filp->f_flags & O_LARGEFILE) && inode->i_size > MAX_NON_LFS) return -EFBIG;

What does strace(1) say it's doing?

It says open("big_file", O_RDONLY|O_NONBLOCK|O_NOCTTY) = -1 EFBIG (File too large) So it sounds like this is right on the money. (Even if the comment you included is wrong, this applies with O_RDONLY, too) -kzm -- If I haven't seen further, it is by standing in the footprints of giants

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 man 2 open describes O_LARGEFILE as follows: O_LARGEFILE: On 32-bit systems that support the Large Files System, allow files whose sizes cannot be represented in 31 bits to be opened. I'm slightly puzzled about why you would need to specify this flag. That is, why would it not just go ahead and open the file anyway? My best guess is that you are promising that all indexes into the file will be 64 bit (unsigned?) ints and not a 32 bit unsigned int. In other words, it's a backward compatability feature with a little typechecking thrown in. - -- Alastair Reid -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+u7CebLKSuD/RJBMRAlD4AJ9nTVio+CoXquE9UtUAUKO5iAEbUQCeK9Ls j1W7OYAmlnMi8p+EdxFDTAo= =yjva -----END PGP SIGNATURE-----

ketil@ii.uib.no (Ketil Z. Malde) writes:

"Simon Marlow" writes:

...

That's probably a bug, as long as the underlying OS uses 64-bit file offsets. How does the 2Gb limit manifest itself?

On Solaris, the file grows until 2Gb, then: Fail: permission denied Action: commitAndReleaseBuffer Handle: {loc=/Home/stip/ketil/data/ug-250.seq.tmp_M,type=writable,binary=False,buffering=block (1024)} Reason: File too large File: /Home/stip/ketil/data/ug-250.seq.tmp_M This file can be read from GHCI, but after I append "foo" to it and try it agin, I get: Prelude> x <- readFile "/Home/stip/ketil/data/ug-250.seq.tmp_M" *** Exception: failed Action: openFile Reason: Value too large for defined data type File: /Home/stip/ketil/data/ug-250.seq.tmp_M

From the manual pages to open(2):

O_LARGEFILE If set, the offset maximum in the open file descrip- tion is the largest value that can be represented correctly in an object of type off64_t. This is with SunOS 5.8. Seems like it behaves quite similar to Linux in this respect. -kzm -- If I haven't seen further, it is by standing in the footprints of giants