Artsize still not quite right in CURRENT
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,
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
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