Hehe, talk about your well composed mail. That's what I get for sending it off in a rush...
Anyway, I've tested with both glibc 2.2.5 (from woody) and glibc 2.3.2 (from sarge) on the same system, with both kernel 2.2.20 (from woody) and kernel 2.4.26 (vanilla kernel, self-compiled), and I figure debian glibc is broken. What happens is that with kernel 2.4.26, when glibc receives a successful lstat64(), glibc decides that something has gone wrong, whereas with 2.2.20, lstat64() fails, and lstat() appears to return the correct values to glibc. Here is a table of what I've tested: GLIBC 2.3.2 (from sarge): strace kernel 2.2.20: lstat64("largefile", 0xbffffc34) = -1 ENOSYS (Function not implemented) lstat("largefile", {st_mode=S_IFREG|0644, st_size=2644920320, ...}) = 0 ltrace kernel 2.2.20: __lxstat(3, 0xbffffebe, 0xbffffd20, 0x4014a550, 0xbffffd78) = 0 strace kernel 2.4.26: lstat64("largefile", {st_mode=S_IFREG|0644, st_size=2644920320, ...}) = 0 ltrace kernel 2.4.26: __lxstat(3, 0xbffffebe, 0xbffffd20, 0x4014a550, 0xbffffd78) = -1 GLIBC 2.2.5 (from woody): strace kernel 2.2.20: lstat64("largefile", 0xbffffc34) = -1 ENOSYS (Function not implemented) lstat("largefile", {st_mode=S_IFREG|0644, st_size=2644920320, ...}) = 0 ltrace kernel 2.2.20: __lxstat(3, 0xbffffebe, 0xbffffd14, 0x4012de48, 0xbffffd6c) = 0 strace kernel 2.4.26: lstat64("largefile", {st_mode=S_IFREG|0644, st_size=2644920320, ...}) = 0 ltrace kernel 2.4.26: __lxstat(3, 0xbffffebe, 0xbffffd14, 0x4012de48, 0xbffffd6c) = -1 Anyone heard of this before? Ketil On Tue, 27 Jul 2004 19:08:26 +0100, Ketil Froyn <[EMAIL PROTECTED]> wrote: > Hi, > > I'm having some problems with lstat() on debian stable and debian > testing with 2.4 kernels. A program that tries to do lstat on a file > bigger than 2gb gets an error. Has anyone else experienced this? I'm > running third party software that requires a functional ltrace(), and > doesn't handle this well. > > The lstat() appears to work with on debian stable with a 2.2 kernel, > but I need 2.4 for hardware support etc. > > I've tested on debian sarge as well, and I get the same results there. > Is this a known problem? Is there a known fix? The same program worked > fine on redhat 8. > Do I have to go back? > > Here is a sample program. Compile like this: > $ gcc -o testlstat testlstat.c > and run like this > $ ./testlstat /path/to/largefile > and watch it fail with ltrace: > $ ltrace ./testlstat /path/to/largefile > > -- testltstat.c -- > #include <sys/types.h> > #include <sys/stat.h> > #include <string.h> > #include <stdio.h> > #include <error.h> > #include <errno.h> > #include <unistd.h> > > int main (int argc, char * argv[]) { > struct stat buf; > if (lstat(argv[1], &buf) == -1) { > printf("error: %s\n",strerror(errno)); > return 1; > } > printf("Success\n"); > return 0; > } > -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]