Hi All,
It seems I can solve the issue by add compile option:
-D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
Thanks,
Erik
在 2011年5月6日 上午10:00，errik 写道：
> Dears,
> As Eric Blake mentioned, ls takes measures to guarantee that
> off_t is 64-bits. There are two problems need your help
> 1) H
Dears,
As Eric Blake mentioned, ls takes measures to guarantee that
off_t is 64-bits. There are two problems need your help
1) How ls do this? I din't notice any clues from the source code of
ls. Sorry for my poor linux coding experience.
2) As in the previous thread, the code ("readdir") h
Stefano Lattarini wrote:
> On Thursday 05 May 2011, Jim Meyering wrote:
>> Green, Paul wrote:
>> > Gentle Coreutils Developers,
>> >
> [HUGE CUT]
>>
>> To the automake folks, is there any reason not to do that?
>>
>
> Hi Jim. I'm in a middle of something else right now, so I'm
> probably not going
Dears,
Actually this is not a bug report, so sorry to do this because I
don't know the mail address of Richard M. Stallman, and David
MacKenzie.
These days, there is a problem that trouble me so much. I write a
simple code to get all the files under a directory and compile the
code on Red
Pádraig Brady wrote:
> This is a theoretical issue really, as if we're
> having issues allocating a few bytes, then the system
> will likely be hosed anyway. But for correctness
> and to aid static analysis...
>
> commit 85c6205f4366edc0d2c50c7036d559acc457509d
> Author: Pádraig Brady
> Date: Th
On Thursday 05 May 2011, Jim Meyering wrote:
> Green, Paul wrote:
> > Gentle Coreutils Developers,
> >
[HUGE CUT]
>
> To the automake folks, is there any reason not to do that?
>
Hi Jim. I'm in a middle of something else right now, so I'm
probably not going to look into this soonish. Could you
This is a theoretical issue really, as if we're
having issues allocating a few bytes, then the system
will likely be hosed anyway. But for correctness
and to aid static analysis...
commit 85c6205f4366edc0d2c50c7036d559acc457509d
Author: Pádraig Brady
Date: Thu May 5 15:20:13 2011 +0100
df:
Philipp Thomas wrote:
> I currently had the task to research the potential pitfalls in updating from
> a rather old version (6.11) of coreutils to the current one. The fact that
> you so precisely state when a fixed bug was introduced greatly helped in
> coming to a compressed list we could then d
I currently had the task to research the potential pitfalls in updating from
a rather old version (6.11) of coreutils to the current one. The fact that
you so precisely state when a fixed bug was introduced greatly helped in
coming to a compressed list we could then discuss.
So I wanted to thank
2011/5/5 Pádraig Brady :
> On 14/04/11 17:10, Yongqiang Yang wrote:
>> Hi,
>>
>> I am off my working computer. Maybe below fix could fix the problem.
>>
>> fs/ext4/extent.c
>> static int ext4_ext_walk_space(struct inode *inode, ext4_lblk_t block,
>> 1877 } else if (block >= le32_to
On 14/04/11 17:10, Yongqiang Yang wrote:
> Hi,
>
> I am off my working computer. Maybe below fix could fix the problem.
>
> fs/ext4/extent.c
> static int ext4_ext_walk_space(struct inode *inode, ext4_lblk_t block,
> 1877 } else if (block >= le32_to_cpu(ex->ee_block)) {
> 1878
11 matches
Mail list logo
