On Fri, May 09, 2003 at 02:43:58PM +0100, Alastair Reid wrote:
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.
SuSv3 doesn't specify a difference between RW and RO. My first guess is unexpected nontermination could occur if something loops until getting some kind of sign it's passed EOF since offsets would wrap so they wanted to avoid that compatibility issue. Anyway, will the following kernel update help clarify things? I'll send it in to akpm et al if so. I've checked with a couple of people and it appears the code is what was intended, not the comment. -- wli ===== fs/open.c 1.38 vs edited ===== --- 1.38/fs/open.c Wed Apr 9 06:42:36 2003 +++ edited/fs/open.c Fri May 9 07:19:25 2003 @@ -902,7 +902,7 @@ /* * Called when an inode is about to be open. - * We use this to disallow opening RW large files on 32bit systems if + * We use this to disallow opening large files on 32bit systems if * the caller didn't specify O_LARGEFILE. On 64bit systems we force * on this flag in sys_open. */