This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: [PATCH] for glibc-2.2 getdents code
>>>>> " " == Jakub Jelinek <jakub@redhat.com> writes:
> But d_type should be completely orthogonal to LFS. It is not
> present in sys_getdents simply because sys_getdents was there
> before d_type was introduced and as userland getdents can call
> sys_getdents64 to get d_type, I have not added sys_newgetdents.
> IMHO the fix is really simple, if kernel nfs client will cast
> the offset for NFSv2 properly (it goes as 32bit value over the
> network AFAIC), then the problem will go away. And if people
> are using NFSv3 and the server passes d_off's which don't fit
> into 32bit off_t, then IMNSHO kernel sys_getdents should fail
> on it the same way as glibc getdents does, because it is better
> to give user error than incorrect information (= silently
> discarded bits from d_off).
No! No! No! How on earth is NFS supposed to know where a cookie came
from and whether or not a sign extension has been performed on it?
Is the cookie 0xFFFFFFFF80000001 on an NFSv3 system a sign extended
32-bit cookie 0x80000001, is it a full 64-bit cookie or what???
I agree that sys_getdents could return EOVERFLOW if we have 64-bit
cookies, however that is not an excuse for glibc to be playing around
with valid 32-bit cookies.
A cookie is an opaque value and cannot be processed.
Cheers,
Trond