This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
LFS and unsigned cookies (was Re: [PATCH] for glibc-2.2 linux-specific getdents code)
- To: NFS devel <nfs-devel at linux dot kernel dot org>
- Subject: LFS and unsigned cookies (was Re: [PATCH] for glibc-2.2 linux-specific getdents code)
- From: Trond Myklebust <trond dot myklebust at fys dot uio dot no>
- Date: Tue, 13 Feb 2001 22:15:35 +0100 (CET)
- Cc: drepper at cygnus dot com (Ulrich Drepper), libc-alpha Mailinglist <libc-alpha at sourceware dot cygnus dot com>, Mogens Kjaer <mk at crc dot dk>
- Reply-To: trond dot myklebust at fys dot uio dot no
Date: Tue, 13 Feb 2001 22:12:12 +0100 (CET)
>>>>> " " == Ulrich Drepper <drepper@redhat.com> writes:
> Trond Myklebust <trond.myklebust@fys.uio.no> writes:
>> No. NFS directory offsets have never been signed. They never
>> were in 2.2.x, and they aren't in 2.4.x.
> It doesn't matter what NFS wants or does, I'm using the kernel
> interface. It is supposed to be filesystem independent.
Hi,
Can anybody with some more background in the details of the LFS
comment on this?
I need to know if anybody on this list finds any justification
either in the LFS specs, POSIX or the kernel interface for why an
unsigned 32-bit cookie of value greater than 2^31-1 should be
disallowed as a readdir offset/cookie?
Currently, glibc-2.2 uses the getdents64 syscall if it is available
(even when the user called the legacy 32-bit getdents). However if the
NFS layer returns a value such as (off64_t)0x08000FFFF as a directory
cookie, this results in glibc returning an error of EOVERFLOW if the
user has called the legacy 32-bit getdents. This in my book seems to
be incorrect behaviour.
Trond