Ticket #656 (new defect)

Opened 10 months ago

Last modified 1 week ago

Linux files can only grow to 2GB

Reported by:	keinfarbton	Assigned to:	sean
Priority:	critical	Milestone:	0.99.8
Component:	Core Functionality	Version:	0.99.1 RC4 Keep
Keywords:		Cc:	sean, larsivi

Description

When using FileConduit? to open and write a file, an exception is thrown when the file size exceeds 2GB. The message: "File size limit exceeded".

This is because Linux needs the option O_LARGEFILE in the open() call. I made a test, adding the value "0100000" (octal) to the open call in FileConduit? and it worked.

Change History

10/03/07 16:37:52 changed by kris

owner changed from sean to kris.
status changed from new to assigned.

thanks Frank. Will fix tonight

10/03/07 16:38:01 changed by kris

status changed from assigned to new.

10/03/07 16:38:22 changed by kris

status changed from new to assigned.

10/04/07 23:33:11 changed by kris

cc set to sean, larsivi.

should we add O_LARGEFILE = 0x8000 to the Posix headers?
should we always open a file in this mode? What are the consequences?

10/05/07 05:48:46 changed by larsivi

owner changed from kris to sean.
status changed from assigned to new.
milestone changed from 0.99.2 RC5 to 0.99.3 RC6.

O_LARGEFILE added to FileConduit? for Linux in [2620].

I think this usually will work ok, it's probably only older systems that may have problems with it. I think we will consider that when that problem arises. The constant should be added to the posix headers instead though, deferring to next release.

(follow-up: ↓ 7 ) 10/05/07 11:50:03 changed by kris

owner changed from sean to kris.

(in reply to: ↑ 6 ) 10/11/07 02:09:45 changed by d3z

Replying to kris: The reason that O_LARGEFILE is not the default is because numerous other syscalls, such as lstat/stat/fstat, and lseek will fail on files larger than 2GB.

Linux does macro/compiler tricks to remap these calls to lstat64/stat64/fstat64 and lseek64 (and probably others) when the C source is compiled with the appropriate arguments.

I would suggest on 32-bit targets, we just use these entry points.

10/11/07 03:28:23 changed by kris

Can we do this, without invoking the wrath we had with read/write protection? Sean? Larsivi?

10/11/07 03:58:14 changed by larsivi

That is certainly a good question - maybe this could be used as an opportunity to get these issues solved once and for all?

11/02/07 17:46:00 changed by kris

owner changed from kris to sean.

11/08/07 19:07:33 changed by sean

Ugh... I tried mapping all the xxx64 functions during our experimentation with read/write protection and something broke mysteriously. I can give it another shot, but it will take some work to get all this code in place. It also doesn't help that these functions are technically nonstandard.

11/12/07 14:46:28 changed by sean

milestone changed from 0.99.3 to 0.99.4.

Pushing off for now.

12/21/07 09:09:59 changed by larsivi

milestone changed from 0.99.4 to 0.99.5.

03/04/08 04:15:19 changed by Jim Panic

milestone changed from 0.99.5 to 0.99.6.

04/27/08 05:08:10 changed by larsivi

milestone changed from 0.99.6 to 0.99.7.

06/17/08 05:01:42 changed by larsivi

07/10/08 07:05:13 changed by larsivi

milestone changed from 0.99.7 to 0.99.8.

Ticket Navigation