On Mon, Oct 25, 2010 at 11:11 PM, Khem Raj <[email protected]> wrote: > On (18/10/10 15:09), Natanael Copa wrote: >> I (or an Alpine linux user) got bitten by the issue below too. >> http://redmine.alpinelinux.org/issues/show/445 >> >> So I started to dig around a bit. Here is what i have come up with: >> * it happens with busybox ls and coreutils ls. >> * it works on 32bit (e)glibc systems. ie ubuntu. >> >> So I compared the straces and as expected, the difference is stat() >> and stat64(). >> >> >From uclibc: >> open("/mnt/iso/", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 >> fstat(3, 0xbffff148) = -1 EOVERFLOW (Value too >> large for defined data type) >> >> >From ubuntu/eglibc: >> open("/mnt/iso/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY|0x80000) = 3 >> fstat64(3, {st_mode=S_IFDIR|0777, st_size=4096, ...}) = 0 >> >> Then i thought that there are probably some flag that is supposed to >> do so fstat = fstat64 or something, and if i know those GNU people >> correctly, they check this in a configure script. this turned out to >> be correct. In the configure output I see this when compiling >> coreutils: >> >> checking for _LARGEFILE_SOURCE value needed for large files... no >> ... >> checking for _FILE_OFFSET_BITS value needed for large files... 64 >> ... >> >> So, I think uclibc is not doing what expected at some place. >> Where or how, I don't know.
> > Do you have large file support turned on in uclibc config ? I have. -- Natanael Copa _______________________________________________ uClibc mailing list [email protected] http://lists.busybox.net/mailman/listinfo/uclibc
