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", 0xbc34) = -1 ENOSYS (Function not implemented)
lstat("largefile", {st_mode=S_IFREG|0644, st_size=2644920320, ...}) = 0
ltrace kernel 2.2.20:
__lxstat(3, 0xbebe, 0xbd20, 0x4014a550, 0xbd78) = 0
strace kernel 2.4.26:
lstat64("largefile", {st_mode=S_IFREG|0644, st_size=2644920320, ...}) = 0
ltrace kernel 2.4.26:
__lxstat(3, 0xbebe, 0xbd20, 0x4014a550, 0xbd78) = -1
GLIBC 2.2.5 (from woody):
strace kernel 2.2.20:
lstat64("largefile", 0xbc34) = -1 ENOSYS (Function not implemented)
lstat("largefile", {st_mode=S_IFREG|0644, st_size=2644920320, ...}) = 0
ltrace kernel 2.2.20:
__lxstat(3, 0xbebe, 0xbd14, 0x4012de48, 0xbd6c) = 0
strace kernel 2.4.26:
lstat64("largefile", {st_mode=S_IFREG|0644, st_size=2644920320, ...}) = 0
ltrace kernel 2.4.26:
__lxstat(3, 0xbebe, 0xbd14, 0x4012de48, 0xbd6c) = -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
> #include
> #include
> #include
> #include
> #include
> #include
>
> 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]
