bug-glibc
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

lseek more than 2GB


From: rob
Subject: lseek more than 2GB
Date: Mon, 16 Dec 2002 19:59:17 -0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021214

I'm using a Gentoo Linux system, and I am having a problem figuring out lseek(). lseek() gives me an error whenever I try to position above the 2GB mark. I compile with "-D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE", but it seems like it's not taking effect.

Here's a sample program and the output:

duron bonnie++-1.02c # cat test.c
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <errno.h>

int main()
{
  int fd;
  off_t offs;
  int i;
  char buf[128];

  fd = open("/dev/hda",O_RDONLY);
  if ( fd < 0 )
   exit(1);

  i = 0;
  while( 1 == 1 )
  {
    offs = (off_t)lseek( fd, (off_t)(i * 1024 * 1024), SEEK_SET );
    if ( offs < (off_t)0 )
    {
      printf("died at i=%d, pos=%lld, errno=%d\n",
             i,(off_t)i*1024*1024,errno);
      exit(2);
    }
    printf("ok at i=%d,pos=%lld\n",i,(off_t)offs);
    if ( read(fd, buf,64) != 64 )
    {
      printf("read died, errno=%d\n",errno);
      exit(3);
    }
    i++;
  }

  return(0);
}
duron bonnie++-1.02c # gcc -D_FILE_OFFSET_BITS=64 -D_GNU_SOURCE -o test test.c && ./test
<snip>
ok at i=2046,pos=2145386496
ok at i=2047,pos=2146435072
died at i=2048, pos=2147483648, errno=22
duron bonnie++-1.02c # uname -a
Linux duron 2.4.20 #4 Fri Dec 13 12:56:31 CST 2002 i686 AMD Athlon(tm) XP 1800+ AuthenticAMD GNU/Linux
duron bonnie++-1.02c #


The machine is running linux kernel 2.4.20, glibc 2.3.1-r2, gcc 3.2.1, and I got the same results on another system with vanilla 2.4.20, glibc 2.2.5-r7 and gcc 3.2-r1. (-r1, -r2, etc are Gentoo-build script version suffixes.)

I tried compiling with "gcc -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_GNU_SOURCE -D_REENTRANT -o test test.c" with the same result.

I tried accessing a data file which is 2959788169 bytes (instead of /dev/hda) with the same result.

Any thoughts?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]