[Ocfs2-tools-devel] [PATCH 1/1] Ocfs2-tools: Let o2image.c also correctly deal with LARGEFILE.

[Coly Li]

Joel Becker Wrote:
> On Fri, Feb 27, 2009 at 03:43:01PM +0800, tristan.ye wrote:
>> On Fri, 2009-02-27 at 15:29 +0800, Coly Li wrote:
>>> Joel Becker Wrote:
>>>> On Tue, Feb 24, 2009 at 10:36:12AM +0800, Tristan Ye wrote:
>>>>> We may not need to switch the open64() on by marco HAVE_OPEN64 here,
>>>>> since actually the HAVE_OPEN64 seems never was defined in the scope of
>>>>> o2image.c. To be more explicit, we simply could use open64() directly since
>>>>> such 64bits utility will never affect on 32bits Linux.
>>>>>
>>>>> Signed-off-by: Tristan Ye <tristan.ye at oracle.com>
>>>> This change is correct anyway, because _LARGEFILE64_SOURCE explicitly
>>>> means we have open64().  If a system is broken enough not to have it, we
>>>> just want to fail.
>>>>
>>> Since include/ocfs2/ocfs2.h declares _LARGEFILES64_SOURCE explicitly, can we say if:
>>> 1) a source file includes "ocfs2/ocfs2.h"
>>> 2) a device file (e.g. /dev/sda or /dev/sda1) to be opened
>>> an open64() should be used other than open() ?
>> Coly,
>>
>> We only need to use 64bits io system call alternatives where large io is
>> going to happen, such as opening a LARGE file, growing a file up to 2G,
>> etc.
>>
>> I personally think there is no need to use open64 to open a device
>> special file, anyway, it may not hurt us if we use 64 bits io system
>> calls everywhere since it only takes effect on a 32bits linux. Joel, how
>> dou you think about it?
> 
> 	I personally use open64() everywhere.  You never know what might
> happen, and it's easier to have open64() and never need it than to be
> stuck with binaries using open() and failing at a 2G boundary.
> 
Oh, a more question: I only know lseek will fail at 2G limitation, will open() also fail on a >2GB
file ?
I just write a test code to open a 2.6G iso file, only open it with open(2) seems OK.

Thanks.
-- 
Coly Li
SuSE Labs