Artsize still not quite right in CURRENT

Fabien Tassin fta at sofaraway.org
Mon Apr 16 14:27:03 UTC 2001


According to Katsuhiro Kondou:
> To: inn-workers at isc.org
> Subject: Re: Artsize still not quite right in CURRENT
> From: Katsuhiro Kondou <kondou at nec.co.jp>
> Date: Mon, 16 Apr 2001 15:07:30 +0900 (JST)
> Sender: inn-workers-bounce at isc.org
> 
> 
> In article <20010414010330.A25065 at opentransit.net>,
> 	Fabien Tassin <fta at sofaraway.org> wrote;
> 
> } strace -tt sm @0302425546303100000000AE4B9F00000007@
> :
> } 00:43:34.664672 pread(4, "7G)M%8D:LB9@", 12, 1553415680) = 12
> 
> Maybe I've got it.  pread(.., offset) does not work as intended.
> offset handed to pread() looks truncated over 4GB.  It should
> be 0xAE4B9F * 512 = 5848382976, but above shows 1553415680 which
> is equal to 5848382976 - 4G(4294967296).  Is that argument treated
> as off_t in those linux box?

I'm using the latest kernel (2.4.3) and glibc 2.1.3.
According to the glibc 2.1.3 doc :

 - Function: ssize_t pread (int FILEDES, void *BUFFER, size_t SIZE,
          off_t OFFSET)
...
     When the source file is compiled with `_FILE_OFFSET_BITS == 64' the
     `pread' function is in fact `pread64' and the type `off_t' has 64
     bits which makes it possible to handle files up to 2^63 bytes in
     length.

but it is not working. I haven't tested with glibc 2.2.* (the doc
reads the same anyway) but reverting to lseek()+read() fixes the problem.

-- 
Fabien Tassin -+- fta at sofaraway.org


More information about the inn-workers mailing list